On May 28, 2006, at 4:42 PM, Nico Klasens wrote:
Daniel Ockeloen wrote:
Hello Daniel,
My previous reply was an attempt to scope the issue of components
which we are solving in this thread. Every issue which you solve
has a scope. Every solution should stay in that scope. The issues,
which I described in the reply and solved by mmbase cvs code, are
totally different from the component issues. The scope of these
issues are completely different than the component scope. The
taglib solves the issue of rapid and scripting-like access, but
that is not one of the issues described in the document of
Johannes. There are two main issues (with sub-issues) in the
document and they both have a scope.
1 What do we need to define a mmbase component.
This is quiet easy, because the applications module and Didactor
are both examples of this.
ehmm 'mmbase cvs code' you mean mmbase as we build it now i guess,
the issues are the same as the component issues since are are trying to
extend 'mmbase cvs code' in a way that it allows the use of
components. With this project we are trying to extend what we see as
mmbase i hope.
2 How can we easily integrate a component in (existing) systems.
this is a lot trickier, but it has a limited scope. We have to
make a list of current existing systems and compare them. Every
system solves a big issue namely the customer requirements. Some of
the sub-issues are solved by mmbase. Others like the templating
issue are custom solutions, because mmbase does not solve those
issues.
Ernst writes about a system (you call it a framework) which should
also be able to use components. Some of the issues in that system
are solved by mmbase. In scope is how that system can integrate a
component, but not how that system will implement how a
component.is integrated. The systen of Ernst provides solutions for
issues/wishes, but they are again not the same issues as we are
discussing now.
I only call it a framework because you call it a framework in the
proposal, there is talk in chaper 2 of frameworks like didactor and
karma. So thats the reason why i talk of frameworks that can run/use
these components if that is the wrong word for it please tell me what
i should call them.
Maybe it is just me, but I just don't understand what the "models"
are. It can't be the way we develop web applications in our
organization, because that is not even on the horizon of the
components scope. My guess is that it is the templating mechanism.
The templating mechanism is not about displaying nodes. It is about
how to aggregate html fragments. This can be done though jsp-
includes, leaf/tree-includes, portals, etc. This is already in the
document of Johannes.
This is the last time ill comment on this part because i think it
takes away from the real questions, models of developement its clear
that there is more than one view inside the community how todo this.
I for one would like to talk to the bridge as little as possible and
do indeed in some ways see mmbase as a scripting language in the form
of the tags.
But ill repeat my core point if i understand the components correctly
any component following the specs should work in any of the
frameworks without changes right ?
My previous email is also the way I view at the software world.
Every piece of software is a solution for an issue someone had.
When you know the issue you also know how big its scope is or
should be. I know a lot of people don't view the software world in
this way. As I mentioned in an earlier email, I am still searching
and this is the way I can understand and decide where to use mmbase
jars. And to stir up some more, most sucessful open source products
are clear on which issue they are solving and what the scope is.
I agree. I think above the bridge we haven't clearly defined what we
want to be. But sofar there has been very little real steering from
the partners and end users in this. If i am to understand it
correctly that is the whole point of this project is to define a
clear way how we can share components that the partners/endusers have
asked for and they provide the resources to create or convert. And if
you want to stir up more check the cvs who are the people who give
stuff back. If this new component system (which i again support
fully) is to have any chance of making it we need help of alot more
than the 5 or 6 commitors we have had over the last year(s). I think
we (the developers) have made a mistake in not earlier trying to
define a component method and i am glad we are working on it now but
its going to need the help of more than just the few commitors that
commit today its going to need the support of the whole community in
a way we have not seen sofar.
I hope we can get to work fast since alot of the proposal are only
slight changes to how it is done in 1.8 and i for one can't wait to
update my contributions in a way that they become these components.
Daniel.
_______________________________________________
Developers mailing list
[email protected]
http://lists.mmbase.org/mailman/listinfo/developers
