cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Max Pfingsthorn" <m.pfingsth...@hippo.nl>
Subject RE: [cforms] rethinking library naming
Date Mon, 26 Sep 2005 17:51:38 GMT
Hi everyone!

> -----Original Message-----
> From: Sylvain Wallez [mailto:sylvain@apache.org]
> Sent: Monday, September 26, 2005 17:24
> To: dev@cocoon.apache.org
> Subject: [cforms] rethinking library naming
> 
> 
> Hi all,
> 
> We started to use the new widget libraries today, 

Nice to see it's used! :D

...
> 
> These names make it very difficult to understand what does what. I'd 
> like therefore to propose a renaming:
> - rename <fd:class> to <fd:macro> (this is the wording used 
> on the wiki 
> [1][2])
> - rename <fd:new> to <fd:expand>: "expanding" is the word used 
> traditionally to denote insertion of the macro contents at 
> the current 
> location.

Hmm. Can we implement <fd:expand> and <fd:new> to be the same and call it <fd:use>
(see below)? Then we can call <fd:class> <fd:define> and say "use the thing defined
there"...

> - rename <fd:import> to <fd:load-library>, to clearly indicate that 
> widgets in the library are made available but not inserted 
> right now, in 
> contrast with <jx:import> in JXTG that executes the imported template.

Like it :)

> - rename <fd:expand> to <fd:insert> (or <fd:use>?)

I would opt for <fd:use> for the reason below.

> 
> For this last item, it has to be noted that it is equivalent to an 
> "untyped extension", i.e.
>     <fd:insert ref="lib:myfield"/>
> is equivalent to
>     <fd:field extends="lib:myfield"/>
> if of course "myfield" is a field.

Hmm. This was initially thought of to be a way to "just use the thing in the library". Usually,
you won't know the type of the widget from the id alone since they should describe concepts
now (i.e. customer, person, address). So, it would be easier to just say "use the address"
than "make a new group which looks like an address"...

By the way, don't forget to make similar changes to the bindings, otherwise it'll be chaos
;)

> 
> Also, I think we should allow <fd:load-library> only as first-level 
> children of <fd:form> and <fd:library>, as it doesn't really 
> make sense 
> to load a library anywhere in a definition, and it further clarifies 
> that libraries are not expanded a the place where they are loaded.
>   <fd:form>
>     <fd:load-library prefix="lib" src="lib.xml"/>
>     <fd:widgets>
>        ....
>     </fd:widgets>
>   </fd:form>

Makes sense.

> 
> We also encountered a problem with classes: if a library 
> defines several 
> cross-referencing classes (i.e. class A has a <fd:new id="B"> 
> and class 
> B has a <fd:new id="A">), then the second <fd:new> fails because it 
> searches in the current form whereas it should search in the 
> originating 
> definition.

Hmm, this is a problem. I'm not sure how to fix this right now either... The problem are deep
new's and expands's which are hard to find and change id's accordingly when another group
definition is used in another form or library. The thing is that we have to have a deep copy
of the corresponding group definitions all the way down the heirarchy graph (since new's can
also occur in groups which can be included), otherwise we change the one which is in the library
object, which is bad if the library is used in different forms with different prefixes. Seems
to be quite hard to do this given the current state of things...

Best regards,

Max Pfingsthorn

Hippo  

Oosteinde 11
1017WT Amsterdam
The Netherlands
Tel  +31 (0)20 5224466
-------------------------------------------------------------
m.pfingsthorn@hippo.nl / www.hippo.nl
--------------------------------------------------------------

Mime
View raw message