[cforms] rethinking library naming
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 WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [cforms] rethinking library naming
Il giorno 26/set/05, alle 17:23, Sylvain Wallez ha scritto: - 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. I'd rather use fd:call-macro or something like that to reinforce the idea that what we are expanding is indeed a macro. Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: [cforms] rethinking library naming
I haven't looked at the new and improved CForms yet, but I'm all for clarification. Sylvain Wallez wrote: 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]) What about the jxmacros? Doesn't that lead to confusion? I know namespace is different, but that is easily lost when scanning quickly through the file. - rename fd:new to fd:expand: expanding is the word used traditionally to denote insertion of the macro contents at the current location. expand does fit better with macro, but I'm having doubts about macro and to me new fits better with class - rename fd:import to fd:load-library, to clearly indicate that widgets in the library are made available but not inserted right now, in +1 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. Well, if both are equal, I'm all for the last (i.e. field extends library 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 +1 Bye, Helma
Re: [cforms] rethinking library naming
Ugo Cei wrote: Il giorno 26/set/05, alle 17:23, Sylvain Wallez ha scritto: - 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. I'd rather use fd:call-macro or something like that to reinforce the idea that what we are expanding is indeed a macro. Hmm... call-macro implies some kind of statement execution, while we are just expanding the contents of the macro... Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [cforms] rethinking library naming
Sylvain Wallez wrote:
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.
+1 to all three proposals
- 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.
do we really need it then? I could live with fd:field extends=lib:myfield/
only :-)
Also, I think we should allow fd:load-library only as first-level
children of fd:form and fd:library, [...]
+1
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: [cforms] rethinking library naming
hepabolu wrote: I haven't looked at the new and improved CForms yet, but I'm all for clarification. Sylvain Wallez wrote: 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]) What about the jxmacros? Doesn't that lead to confusion? I know namespace is different, but that is easily lost when scanning quickly through the file. Ah, you mean ft:class which would be replaced with ft:macro and thus could be confused with jx:macro? Hmm... Not sure this is that much a problem. - rename fd:new to fd:expand: expanding is the word used traditionally to denote insertion of the macro contents at the current location. expand does fit better with macro, but I'm having doubts about macro and to me new fits better with class - rename fd:import to fd:load-library, to clearly indicate that widgets in the library are made available but not inserted right now, in +1 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. Well, if both are equal, I'm all for the last (i.e. field extends library field). They're not exacly equivalent. fd:field extends=lib:myfield/ is an extension with no overloading or extension and thus must use the exact same widget type as the extended widget. Since it doesn't allow overloading, ft:insert doesn't care about the library widget's type, and avoiding having to know the target widget's type can be convenient when you just want to use it. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [cforms] rethinking library naming
Reinhard Poetz wrote: Sylvain Wallez wrote: 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. +1 to all three proposals - 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. do we really need it then? I could live with fd:field extends=lib:myfield/ only :-) Sure. fd:insert adds a little more convenience you don't extend the widget (see my answer to Helma). Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
RE: [cforms] rethinking library naming
Hi everyone! -Original Message- From: Sylvain Wallez [mailto:[EMAIL PROTECTED] 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 - [EMAIL PROTECTED] / www.hippo.nl --
