Henk Hangyi wrote:
Hi Kees,
It never felt right to extend Builder to add functionality.
Why not? It is great fun and very valuable both from a theoretical as
well as a practical point of view.
That never worked good enough for my needs. The real problem
IMHO is that it's not easy to program against MMBase using
java. My solution is well known. I just write a lot of
I agree with you and at the same time disagree, because yes, the API of
MMBase contains a lot of unclear and redundant parts, but on the other
hand its object orientation, relation management and extendibility is a
big advantage in building professional webapplications. And of course if
you talk about real-time multiuser games, then the performance for
MMBase is not good enough. But for a lot goals its performance is more
than sufficient.
jsp/taglib code and that just works , it doesn't need the
compile/deploy cycle and develops quite fast. and if you are
creating website at least You know where to find the code.
While it's a solution , to me it's telling me that MMBase is
great product for fast/ad-hoc development(If you already know
MMBase that is) but You need to compare it to other emerging
technology like the Rails framework or just for that matter
good old php/MysqlAdmin.
Yes i think MMBase great for ad-hoc development, but when it comes to
professional use you can (and should) also scale it towards a strict MVC
approach. In these situations PHP/MysqlAdmin is not an option at all.
I totally agree with nico about the session stuff and vague
concepts. I also agree with Michiel he is trying to make
..
very important but are not concentrating on what the
developer want or what the user want :)
I agree with you and Nico on this point.
hello developers
let me first say that i think this is a great discussion, and a very
important one. MMBase is being 'overcast' by a number of frameworks that
seem to work well, and each address a part of the problem that mmbase is
(trying to) solve in one stop.
-Hybernate is better in performance but less flexible in it's datamodel
approach.
-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.
But the focus and clarity of design of these products do bring the
somewhat vagueness of archtecture of mmbase to the light. I think most
people that know mmbase quite well don't know many things about it at
the same time. The bridge is a good example. Who knows exactly what
happens there (like Nico says)? Each time you have to look, and some
details are hard to remember becouse they are simply illogical. or
non-intuitive.
I wonder if we could use the decorator pattern to sort out the builder
and node issue. For instance, we could have a basic Node, that only
knows it's data and it's builder and it's relations and so on. Then you
could create decorators for:
- security
- persistance
- versioning
- i19n
That way the core could work with nodes without a security decorator
(Michiel's argument for having security in the bridge) and the context
would allways give nodes with the securty decorator.
I must admit i havn't thought this though entirely (probably don't have
the brain for it anyway :-) ), but the heart of the matter is that i
agree with most people that the mmbase api is not terribly clear, and
could use some serious restructuring. The node builder situation
especially, as this is the core of mmbase. Perhaps this approach would
allow the node object to grow without braking it's interface or creating
all kinds of 'special code in special places' to make things work right.
I also value the rapid development side of mmbase very highly. Using
uml2mmbase makes creating a cloud a breeze, and the generated wizards
are at least a good starting point for what you really want. So i
consider this definitely a strong point of mmbase that could even be
extended upon.
Maybe we should organize a theme day for this subject, becouse it is
quite important. I think Michiels idears for 1.9 are good, but we really
need to know a lot more before we can say: "mmbase 2.0 is going to be
like this".
regards,
Ernst
main resons). A nice addition would be a framework that
support the Strong points of MMBase (no compile/deploy
cycle).
What is the problem with the compile/deploy cycle? I think there are two
groups of users: (1) using MMBase out-of-the-box for building websites /
small-webapplications => no compiling needed or (2) using MMBase for
professional web-applications => you can not do without a compile/deploy
cycle. And then i dont see why we should redo the MVC approach, where
Struts or JSF can already be used in combination with MMBase.
components can be scripted. I should be fun and we should be
able to do AJAX and such stuff in a breeze or am I missing
the point?
I was thinking about scriptability as well. Logical extention points as
wel as framework callbacks could be scriptable, alowing you to develop
'as you go' and making a clear separation between the framework and the
application (something extending MMObjectBuilder definitely dous not)
what could be made scriptable:
- event handlers
- framework callbacks
- functions (node, nodule, builder,..)
- ...
AJAX in a breeze that would be great.
Kind regards, Henk.
_______________________________________________
Developers mailing list
[email protected]
http://lists.mmbase.org/mailman/listinfo/developers
_______________________________________________
Developers mailing list
[email protected]
http://lists.mmbase.org/mailman/listinfo/developers
