Hi Ernst,
I will not react to your document point by point. I would rather react to the assumptions (i think) lie behind it.
I believe this is dangerous, because you assume a lot about my motivation. My underlying idea is completely different from what you think it is, and I think we have more things we agree on than we disagree on.
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.
Agreed, hence this effort.
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'.
Let me clarify that I am NOT working for Finalist, and whether or not they really think of mmbase as a only datadump, I don't agree with this approach. So I agree with you on this point completely: MMBase is much more than a fancy database.
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.
Agreed, in my current projects I use this exact approach: use functions for harder business logic, and all other things in taglib.
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.
I never said that components should be written in java. Actually I just propose some extra tags to be used in components (your applications if you like), so that they can be generic. Ofcourse these tags need java code behind them, and for THAT I propose to write interfaces. Only if you are a framework-builder you need to write java, all other people will write with taglibs.
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.
Indeed, but that is out of scope for this document.
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)
Yes, maybe and yes. These strong conventions will be part of this proposal, they are just not written down in detail. I don't really understand your second point, but I agree with the 3rd, again, that is what this document is about. I only described those areas on which I think that you must write a specific solution for your specific framework (in java), which can be accessed from your application through taglibs.
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.
Trying to enforce default builders upon all current MMBase implementations will get you a lot of problems. Nobody will agree on them, nobody will want to migrate their databases, and this project will die a slow death.
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 don't want to be forced into writing portlets. I want to leave this open. But I agree that this needs more focus in my document.
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).
Many people have commented on this mixin idea sofar, with different approaches. I think it is best to move this discussion to a meeting.
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.
This is definately not the approach I am suggesting. Only that a framework for mmbase should implement some java interfaces to allow components (applications) to be run on them. Hope this clarifies things, Johannes _______________________________________________ Developers mailing list [email protected] http://lists.mmbase.org/mailman/listinfo/developers
