hi
I will not react to your document point by point. I would rather react
to the assumptions (i think) lie behind it.
There is a lot of talk about the need for a framework or container that
can make bits of functionality work together. This is a very good idea.
What i wonder though is how this should be approached. Finalist chose
for a very 'dominant' solution, where the the role of mmbase is
marginalized to that of 'datapump'. I feel there is not a lot of
attention for what is already there and what approach is in line with
the 'mmbase way of things'.
Mmbase has a lot of power in the tag lib, so what happens is that a lot
is being done in templates. Adding functions to the equation even made
this a more attractive approach, striking a nice balance between
presentation-code separation and ease of use.
If you would have to implement java interfaces to translate the
functionality of your application to the container, you loose that
power, and you may loose investment in developed functions as well, if
it turns out that calling functions is not a conveneant way to implement
the interface. The whole thing becomes very java-centric which i think
would be a loss.
Personally i would rather see a move in the other direction where it
becomes more and more easy to develop with mmbase, also for non-java
programmers. Idears in that direction comprise adding scripting support
for scritable functions and system callbacks, and development of better
(gui) tools.
So, i think that if you want to address the problem of reuse of mmbase
functionality, you should try to do it as non-obtrusive as possible.
this can be achieved in several ways:
- strong convention: (i don't need a java interface to a functionality
if i can look at the cloud design and use it with the tag lib.)
- formalizing existing solutions
- think of clear boundaries to the areas you want to manage (don't
manage everything)
So: builder name blurr can be overcome by choosing default builders (we
don't need mixin for that), also by using application dependencies you
can already define collaboration between functionality and reuse.
I think the apps1 spec is not complete, and apps2 is still hanging
there.. Still, maybe this is all we really need. Maybe we should focus
more on creating those applications, that use each other and integrate
well, and provide the documentation and information needed to reuse them
successfully.
Perhaps special attention should go to how different 'applications'
interact in one screen. The portlet spec. has an answer to that, but
perhaps we could think of something that is much more in line with the
current way of things. Something more lightweight, again more based on
convention. Something that is just as easily used as ignored.
I can imaging the mixin idea can be very interesting if this means you
can define 'meta objects' what i mean is an object consisting of
different nodes. Say, an article meta object, consisting of an article
node, some paragraph nodes, and some image nodes. I can imagine that
could have a lot of use (also for import export purposes).
So, in conclusion, i am not really happy with where this is all going.
Finalist is obviously driving this towards an architecture where java
programming is central to mmbase development (it's what they do after
all), and mmbase is just one more framework in their stack. I think
mmbase has some properties that make it different from all those (very
nice) j2ee spinoff api's, and i think we should expand on that, in stead
of marginalize.
regards,
Ernst
Johannes Verelst wrote:
Hi all,
As some of you know (and probably others don't), I have been busy
together with Nico Klasesn to see if there is a way to create an
"MMBase framework". The reason is simple: many companies have spent
huge amounts of money for custom MMBase implementations, and
components in those implementations are never given back to the
community. One of the reasons is because of the 'lock-in' to their own
framework which was built on top of MMBase.
With many frameworks already in existance, and the need for "generic
components", I looked with Nico at Didactor, the EO site and to
finalist's Karma/CMSC. The result of this session is now a word
document that I attach here (html version also added).
The main suggestion is: don't enforce a "great unified mmbase
framework", but work the other way around: define some interfaces that
frameworks should implement and components must use. That way every
framework can keep its own way of doing things. So, don't enforce
people to use either tree-include or leaf-include, but create an
interface for creating URLs for which the EO will write an
implementation for their framework which generates urls based on
leaf-include.
Next week, on the symposium organized by Jo, I will present this
proposal to parties interested in a mechanism to share components
between parties. Currently it is "my" proposal (together with Nico),
but I would hope it could be "our" proposal. For that I need your
comments, insights and possibly even flamewars :).
Johannes
------------------------------------------------------------------------
_______________________________________________
Developers mailing list
[email protected]
http://lists.mmbase.org/mailman/listinfo/developers
_______________________________________________
Developers mailing list
[email protected]
http://lists.mmbase.org/mailman/listinfo/developers
