Max Pfingsthorn wrote:
Hi!
Thanks for the comments, got some more though ;)
<snip/>
I would avoid if possible instance-build-time for performance reasons.
About reload management, there could be a kind of include tracker where all includes files are registered.
For now, I thought I might handle it within one library object. A library might
have a dependenciesHaveChanged() method, which would access the local map of
dependencies and ask the librarymanager if they have changed. This method might
be called after the librarymanager knows that this library hasn't changed.
E.g.:
Library lib = (Library)this.cacheManager.get(source, PREFIX);
if(lib!=null && lib.dependenciesHaveChanged()) {
lib = null;
}
if(lib==null) {
// load library specified by source
}
The librarymanager would then sort of recursively ask the libraries and we
would get a path of regeneration where needed.
Makes sense. Check the direct dependencies which in turn check their
direct dependencies, etc.
I may have missed something, but this "replace" thing seems to me to
introduce way too much complexity. If you make the analogy
with classes,
a subclass cannot remove a method of its parent class and replace it
with something else. It can however overload it to provide
more, while
still respecting the contract of the parent class.
Yes, but what is the contract of a widget with the model? That the type stays
the same? If you think about macros more in terms of a template, then you might
need to replace something. But I agree, replace seems a little out of place.
Hmm... I wouldn't go as far as considering macros as a template. If you
really need that flexibility, then use a pipeline to build the form
definition!
<snip/>
What do you mean by "deep copying"? Is it copying in a definition the
elements that are reused from the definition it extends? I
don't think
it should be deep: since a definition is immutable, just copying the
needed information from the extended definition should be enough.
Yes, but we want definitions to be mutable, otherwise we cant change it anymore
by extending it.
?? Why does extending a definition modify it? The extension definition
should grab what it needs from the definition it extends, but not modify
it. Also, how can you handle multiple definitions extending a single one
if extending means modifying?
Or Builders can somehow go around the immutability. The way I think it might be
is that definitions should be kept in the library objects. However, multiple
widgets, and therefore definitions, might be derived from a particular
definition in the library. Since we are dealing with references all the time,
we would change the original definition object while deriving if we didn't make
a complete copy of it first.
Hmm... Not sure I got everything, but I insist on the immutability of
definitions. If a library has changed, then it is rebuilt, and any
definitions currently in use (through instances on which users are
currently acting) still use the previous version of the definitions.
Ah: Or the builders would be kept by the library. Then they can pump out new
definition objects for every time one is requested. This would mean though that
the builders would have some state, which is not the case right now. And I
guess the whole point was to _not_ reparse the xml all the time.
Builders parse the XML and build definitions from it. If a library is
stored as a set of definitions, I don't see why reparsing the XML would
be needed when a definition uses a library?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
