cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Upayavira ...@odoko.co.uk>
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


Mime
View raw message