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 --------------------------------------------------------------
