CodeExtinguisher Release Candidate 11

[eluser]Majd Taby[/eluser]
elitemedia, this is a community effort. Send me your username and password and i'll give your full SVN write privileges

p.s. If you screw up, we can just roll back

GDmac, the OneToMany plugin has been updated in the repo. After some testing, i'll release RC12

[eluser]Thoer[/eluser]
I'll post a note for sure, but we'll have to ask jTaby to give translator accesses...

[eluser]Référencement Google[/eluser]
as username put 'elitemedia' as password make me an autogenerated password that you will send to me in PM.

[eluser]GDmac - expocom[/eluser]
jTaby, can you put some links up on http://codeextinguisher.com/ homepage
to the wiki and to the repository?

[eluser]GDmac - expocom[/eluser]
Just my .2 cents (had to relieve my heart)... i think Extinguisher is heading in a stray direction.
First, the error log... it is a stark contrast what CI notifies you of and the hell you have to debug
yml, model, controller and issues with CE. So think about feedback on a low level.
Second. Code comments. if you don't have time to make documentation, at least
document functions and classes. First, they give a great feedback to anybody who wants
to understand what the code does, and second if you set up commenting the right way,
you can even extract the documentation direct from source. (google for it)
Last but not least. I have big questions about the auto crud stuff and yml.
at the moment they are more in the way of actually grasping the tool and being usefull.
and i really would opt for solid models where you have a good view of your idea of what you
want to accomplish (join customers with orders and payments or join games with reviews
and pricing tables) instead of a tool that tries to be an automated table lurker but will fail
at tweaky config or automated stuff that at the edge doesn't work.
...
phew... so, not to sound negative or bewildering. CRUD and ease of config are great assets,
but i DO think that users should have an idea of their data-model and then set the config accordingly,
before they dive into the website or just start adding tables.
At the moment CE is to much loosing its edge on a solid model-control (relations, validation,
unique fields etc.). for me it means, back to basics (CI).
--
(edit: "...specs are like flossing: everybody knows they should be writing them, but nobody does. ...
http://www.joelonsoftware.com/articles/f...00036.html )

[eluser]andjules[/eluser]
my 2¢ back:

as for code-commenting, yup, I agree it'd be a nice place to start learning
as for a model-based approach, if you read the first page, that's on jTaby's roadmap*
as for YAML being in the way, well, the spyc parser can be a little finnicky, but having used YAML on other projects, it takes about 5 minutes to get used to it, and it's way more fun/readable/scan-able than php code or XML.

it's not always ideal, but for me, adjusting my project approach to CE's way of doing things is a lot easier than i) trying to hack it to think like me, or ii) going "back to basics (CI)" and trying to make beautiful admins by hand.

* with models in the roadmap, maybe this was a bit harsh?:

i don’t think Extinguisher is heading in the right direction

I'm still pumped that CE even exists! the quality of the admin generation tools is a big deciding factor for me when looking at a framework.

[eluser]GDmac - expocom[/eluser]
andjules: "... the quality of the admin generation tools is a big deciding factor for me when looking at a framework.". I Agree totally, but it should follow from your model before (pardon my denigration) pretty scaffolding. For that we have phpMyAdmin. I rather have a solid model foundation than a pretty (data/)table-editor. But don't get me wrong. i really look forward to some amazing stuff this will bring forward (like the Khaos rights engine).
(edit: medium-enterprise-level) (edit2: my critique is at beer-level 9, so take with grain of salt)

[eluser]Majd Taby[/eluser]
Don't worry about sounding negative.

I'll try to address your points one-by-one. But first, let me start by saying that I understand how frustrating the lack of documentation is. The same issue goes with the ManyToMany and OneToMany plugins. That's why codex is in beta. These things need to be addressed.

I'll tell you how I personally feel. I feel like the code that runs codex is in dire need of refactoring. There is a lot of code repetition in the files, and I plan on fixing that as well.

Those are two of the overarching problems that I see with codex that I am working on fixing.

First, the error log… it is a stark contrast what CI notifies you of and the hell you have to debug
yml, model, controller and issues with CE. So think about feedback on a low level.

I agree, I plan on working on that.

Second. Code comments. if you don’t have time to make documentation, at least
document functions and classes. First, they give a great feedback to anybody who wants
to understand what the code does, and second if you set up commenting the right way,
you can even extract the documentation direct from source. (google for it)

In its current state, yes, I need more commenting to let the user know what the heck is going on.

Last but not least. I have big questions about the auto crud stuff and yml.
at the moment they are more in the way of actually grasping the tool and being usefull.

This is an area where I have to both agree and disagree with you. The spyc library needs to be replaced. On the other hand, I think YAML is very useful and maintainable. Besides, don't forget that you can go ahead and use straight-up PHP without touching YAML if you wish to do so (a fact which would be covered in the docs)

and i really would opt for solid models where you have a good view of your idea of what you
want to accomplish (join customers with orders and payments or join games with reviews
and pricing tables) instead of a tool that tries to be an automated table lurker but will fail
at tweaky config or automated stuff that at the edge doesn’t work.

If you look at the first page, you will see that I have models as a future feature. But lately I was thinking about it, and I figured that the current system works fine. I understand what you are trying to say. But don't forget that you can create pages through controllers. the CRUD controller simply provides an automated, generalized alternative. As far as "at the edge doesn't work", i'm working on it. Codex isn't at a final release yet.

but i DO think that users should have an idea of their data-model and then set the config accordingly,
before they dive into the website or just start adding tables.

CodeExtinguisher is meant as a drop-in. If you want to design your data first, then do so. At the end, simply drop codex in and tell it what kind of plugins to show.


I don't want to sound dismissive, but I think if you hold your judgement until the docs are finished, and give them a thorough read, then most (if not all) of your issues will be addressed.

In conclusion, why don't you help make codex better?

[eluser]GDmac - expocom[/eluser]
Thanks jTab, that was a great response. and to be honest, i really like a efficient CRUD tool for our websites.
if you like i can add some docs and maybe a bug-report here and there.
(next week, /me now of filming couple o' days)

[eluser]Majd Taby[/eluser]
GDmac, send me a PM