Daniel Ockeloen wrote:
On May 12, 2006, at 11:53 AM, Ernst Bunders wrote:
Kees Jongenburger wrote:
-Hybernate is better in performance but less flexible in it's
datamodel
approach.
it's the opposite
-ejb is very powerfull and very structured, but unsutable for rapid
development (i think, without knowing the world about ejb).
-spring delivers a strong separation between your code and the
framework
(as well as a means to intergrate different frameworks smoothly), but
requires you to use java where mmbase allows you to use tablib,
which is
very user friendly.
Of course we are comparing a a framework with a CMS,
this is an interesting point, but i nearly let it slip...
Wat is the definition of a CMS? that it merely allows you to reach
content and perhaps modify it? but what is the difference between
'content' and 'data' and what happens to the CMS if all kinds of
business rules are added to make sure the right things happen to the
data? is it still a CMS? or has it become an middle tier application
framework? I have seen many mmbase projects that blurry the line as
much as possible, using mmbase as an application framework and find
it wanting. More so, if mmbase were 'just' a CMS would we have all
this discussion about where and how to extend (read: add your own
business rules to) mmbase??
It is an interesting point because the fundamental question about
mmbase 2 is: what is mmbase? How dous it relate to all these
frameworks that do a bit of the same?
I think the answers to these questions should be hour guide towards
an mmbase 2.0 design.
Ernst
whatever you call it i think we already took this step. MMBase 2.0 will
move to a place where it does more than just the old cms but become a
place where we can share real applications/components in a useful way.
For me the main reason is the sharing on the core its not easy to share
(and its not that needed except for a few core developers) but sofar
ontop of the core we didn't set out many rules and so we have no way of
sharing. The upcoming framework ideas will try to solve that. Let me be
very clear i don't see MMBase going anywhere if we don't solve this
issue so if you don't agree please yell now or ehmmm forever ... you
know the drill :). The reason that we are getitng mutliple frameworks
ontop is the reason why action is needed since you can't share things
if you don't have a common framework.
for me it is obveous that mmbase is moving towards an application
framework, but i find it intersting that Kees dous not seem to think so.
I agree with you we have to be (at least in principle) of one mind about
the purpose and future of mmbase, if we want to drag it (kicking and
screaming) into the age of the fruitebat...
Daniel.
_______________________________________________
Developers mailing list
[email protected]
http://lists.mmbase.org/mailman/listinfo/developers
_______________________________________________
Developers mailing list
[email protected]
http://lists.mmbase.org/mailman/listinfo/developers