cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Max Pfingsthorn" <>
Subject Cforms Library design decision(s)
Date Tue, 26 Jul 2005 11:53:15 GMT
Hi everyone!

First of all, thank you very much for your warm welcome on our little excursion to ApacheCon
last week! It was great! :)

Now, it is down to business for me though. I discussed with Silvain about the problem of inclusion/inheritance/partial
definitions briefly. It is rather easy to do this using xslt/pipelines/cincludes, however
it may be more beneficial using generating something like the Java Form model from libraries
instead. Speed may be an advantage here.

I've tried out some things and here are some pros/cons. Maybe we can discuss about it briefly
here so my additions are usable.

PRO xslt:
- rapidly developed (existing stylesheets)
- caching comes for free (?)

CON xslt:
- reparses shared definitions all the time
- not so easy to detect inclusion loops
- rather inflexible, if you don't want to go into parameter passing hell

PRO objects:
- more time efficient (marginally, I guess)
- easy to detect (and resolve? -> partial definitions) inclusion loops
- general cleanup of widgets/widgetdefintions/widgetdefinitionbuilders comes along, which
should happen anyway
- easier to extend and build special cases

CON objects:
- not so rapid development
- caching must be implemented, otherwise old problem of editing the second inclusion level
which doesn't get checked anymore

I guess this shows I should go for the object model, but what do you guys think?

My plan so far is this:
1. Implement extra LibraryDefinition and LibraryDefintionBuilder, etc (taking hints/code from
the whiteboard)
2. Finish porting Whiteboard code to trunk version of forms
3. Move config verification code to the defintion classes and out of the builders so partial
defintions become possible
4. Define some inheritance rules in the definition builders (e.g. you can't override a widget's
type, or you can only add new validators, etc)
5. Write javadoc while coding (of course) and user doc with samples
6. Write unit tests.. I only see one in svn, so I guess this is something to work on anyway...

I would think that I can do 1/2 and maybe 3 until next week. After that, it would be time
for a little demo, I guess, so to make the bugs shallow ;) After bugs are mostly taken care
of, it should be rather downhill. Lots to write, but no deep thinking required.

Also, Reinhard asked me to come up with some rules to measure my success in. I would say the
points I mentioned before are my deliverables, and since there are so little test cases for
now (only for the field widget), we make 6. optional? I don't have that much experience in
writing test cases and I think, regarding form's unstable status and the renaming campaign
between 2.1.6 and 2.1.7, it is not really the main point right now.

What do you guys think about the plan?

Then again, I don't know what will happen in the main trunk after I fork to whiteboard...
Will something major happen in the next 3 weeks within forms or the blocks in general? Especially
with all that OSGi stuff going on? Or am I safe over August where everyone goes on vacation


View raw message