cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject [cforms] rethinking library naming
Date Mon, 26 Sep 2005 15:23:50 GMT
Hi all,

We started to use the new widget libraries today, and encountered a 
number of semantic issues, mainly related to difficulties to clearly map 
names to concepts.

To use libraries, we currently have at hand:
- <fd:import> to make a library available for reuse in the current form 
(or library) definition.
- <fd:expand> to import a widget defined in a library in the current 
definition
- <fd:class> to define a group of widgets with no surrounding container
- <fd:new> to expand the contents of a <fd:class> in the current container

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.
- 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.
- rename <fd:expand> to <fd:insert> (or <fd:use>?)

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.

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>

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.

WDYT?

Sylvain

[1] http://wiki.apache.org/cocoon/CocoonFormsScratchpad
[2] http://wiki.apache.org/cocoon/WhiteBoardCocoonForms

-- 
Sylvain Wallez                        Anyware Technologies
http://people.apache.org/~sylvain     http://www.anyware-tech.com
Apache Software Foundation Member     Research & Technology Director


Mime
View raw message