cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Upayavira>
Subject Re: Cforms Library design decision(s)
Date Tue, 26 Jul 2005 18:59:30 GMT
Joerg Heinicke wrote:
> On 26.07.2005 13:53, Max Pfingsthorn wrote:
>> 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.
>  >
>> I guess this shows I should go for the object model, but what do you 
>> guys think?
> Hi Max,
> I also prefer the objects - and if it would only be for easier debugging 
> in case of errors. The rapid development is not so important IMO, 
> because a "normal" user should not come in touch with this code - it 
> belongs to the CForms framework. And if he needs to get in touch with 
> it, then because he needs very special stuff - and here - you already 
> pointed it out - XSLT can be a mess.
>> 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...
> Sounds good.
>> 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.
> But it would be extremely cool ;-)
>> 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 anyway?
> I don't think that major thinks will happen, but I don't know the plans 
> of others of course. About OSGi: Isn't it minimal invasive - so why 
> should it have any influence? ;-)

No, Max, just get on with it in your own branch in whiteboard. If stuff 
moves, well, we'll deal with that when we come to do a merge. If it has 
moved in trunk, we move it in your branch, then do the merge. No-one 
will ever be able to second guess what is actually going to happen in 
our SVN, so best just get on with it now.

Regards, Upayavira

View raw message