Daniel Fagerstrom wrote:
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.
Wow, wow, wow! What a complicated process for just integrating two
pieces of the puzzle, even if it's "smart" integration.
Let me just explain how this works:
- I added two classes to CForms (about 3 weeks ago), namely
ContainerAsMap and RepeaterAsList. These classes are a Map and a List
implementations (live wrappers) on top of a container widget and a
repeater respectively.
- I added jdbi.jar, a 64k jar that provides List and Map implementations
on top of a JDBC ResultSet (List for all rows, Map for one row), and
PreparedStatements with named parameters fetched from a Map rather than
positional parameters as regular JDBC
And the rest is just about using the collection API. Map.putAll(),
List.addAll(), plus a bit of JS glue to have a more JS-friendly syntax.
Do we need whiteboard, incubation, and all this when this changes
*nothing* to existing code and just start its life as a sample?
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.
Killing this experiment means killing a sample. Samples aren't part of
our public API.
--- 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.
I agree with both you and Andrew. We have some junk in Cocoon (who uses
DB modules?) but don't know what people are using. And we have a strong
tradition of backwards compatibility, and also some kind of "kindness"
or "respect" regarding old stuff and those that wrote it that prevents
us from deleting it.
--- 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.
Does it? It seems to me that the problem is more related to peripheral
stuff that nobody uses than the core itself.
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.
SQL, Forms, List and Maps. Is this new functionality?
* 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 go back to the discussion about blocks/stable, blocks/unstable, etc.
blocks/* and some status information should do the job equally well.
* 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?
Or simply left as is in 2.1 and removed in 2.2.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
