was: Super-easy SQL/Form integration for simple CRUD applications
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
Sylvain,
It seem to be great stuff, and something that we really need. But
being somewhat formalistic I'm a bit doubtfull about the timing. Ok,
you committed it before the freeze, but not in good enough time to
make much community involvment possible before the release.
This is just an sample with 300 lines of highly-commented flowscript,
one form definition and two page templates (not counting the sitemap
which is rather standard nor static resources).
Do we need a vote to add a new sample?
We certainly don't need to vote for adding a new sample. But IMO what
you added is much more important than "just a sample". It adds new
functionality: "SQL/Form integration" and show new better application
patterns than previous ones (you removed an obsolete way of doing
something similar) and it add a new dependency.
Just because of its importance, you agree that it is important don't you
;) we should follow our usual and well proven development patterns which
involves community involvement.
So I would have prefered if you had started to add your SQL/Form
integration samples to the whiteboard and started a discussion about it
on the list. Then if there is enough community involvement (which I
assume it would be), and after having taken relevant feedback into
account you could say that you are moving it to an own block and after
having got lazy concensus you could actually move it.
Now, with such a process it wouldn't have made it to 2.1.8, but 2.1.x is
supposed to be a bug fix branch rather than a branch for new experiments.
--- o0o ---
I'm sorry for picking on you when you add such nice and important
functionality. But the code base of Cocoon is rather hard to manage
today as the accumulated effect of all these small additions that each
in itself seemed to be a good idea. But many of them didin't actually
take off and didn't become integrated with the rest of the
functionallity in Cocoon. And we haven't deprecated much either.
So IMO we need to have a serious discussion about how to add new blocks
and new functionality to Cocoon.
As I said in another message: Today anybody can just add a block, but we
all are supposed to be responsible for them.
And what is much worse: we never remove anything.
So, taking DB-handling as an example: in the databases block we have
ESQL, modular DB modules and actions and the SQLTransformer, three
different approaches to do the same thing, all of them considered to be
obsolete. Furthermore we have the OJB block that is still another and
maybe better way of handling DBs, and now we have your new stuff.
--- o0o ---
Keeping all the old stuff forever makes it less and less fun to develop
Cocoon: We want M2, ok then someone have to write +50 POMs, we want real
blocks, ok +50 block descriptors and manifest files. And all the 200
jars must be kept up to date etc. The core becomes more and more
complicated to keep it back compatible with every single idea that we
ever have put into it. We should have unit tests for everything, except
for the enourmous amount of work it would be to write them, it would
take hours to run them.
--- o0o ---
Ok, enough complaining ;) So what do I propose?
* New kind of functionality should (in general) go to new blocks.
* New blocks should go through some incubation process, starting in the
whiteboard and needing a small community and a vote to get out from there.
* We really need to get rid of obsolete stuff. Must really every single
block go to 2.2? Are there some oneman shows that better could be
returned to their creator and driven on source forge or Cocoon-dev?
WDYT?
/Daniel
