cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
Subject Re: [cforms] Forwarding catalog discussion
Date Mon, 05 Jan 2004 16:06:07 GMT


Tim Larson wrote:

> [Forwarding private email snippets (with permission) to list.
>  More topics will follow under different subject lines.]
> 
> 
>>--- Marc Portier <mpo@outerthought.org> wrote:
> 
> yep, and I'm afraid I haven't listened enough to the need you want to 
> address, the more I think about the class-new stuff the more I end up 
> thinking about some central catalog
> 
> 
>>--- Tim Larson <timlarsonwork@yahoo.com> wrote:
> 
> There should be a central catalog, but I think we also need to be able
> to have classes that are local to a form.  Now that the local case has
> been implemented someone can extend "new" to also be able to reference
> a central catalog.
> 
> BTW, I was thinking about allowing multiple catalogs and using "import"
> to reference in the relevant catalogs or specific classes from certain
> catalogs, similar to how import works in java source code.  WDYT?
> 
> [Note this would also be similar to import/include in XSLT.]
> 
> 
>>--- Marc Portier <mpo@outerthought.org> wrote:
> 
> I was thinking about augmenting the default-manager with a reference to 
> a catalog where all the 'classes' are
> 
> and then have the new look those up from there, they should then have a 
> logical-name, and should get a specific id in the new definition...
> 
> still thinking though
> 
> [End of email snippets]
> 


More background from my side:

my bias towards central stuff is lowered, I see know how we can merge 
the two and indeed postpone the central thing until we have a more clear 
view on the advatages of these new things

however, my escape towards the central stuff was driven by a very strong 
(IMHO crucial) believe that all created definition and binding classes 
should become immutables: created once, reused all over, and that we 
should try to resolve all dynamics either during the build or inside the 
widget-instance-tree

in fact, the reason that I lowered my stress on central stuff, is that 
during discussions we somewhat found a conceptual way  to support the 
local-class/new stuff while still holding onto the goal of immutables 
(although I need some more thought on that)

so to me, the roadmap: central catalog later makes sense

I would however like to here other visions on the immutables vision 
however...

regards,
-marc=
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                http://blogs.cocoondev.org/mpo/
mpo@outerthought.org                              mpo@apache.org


Mime
View raw message