Daniel Ockeloen wrote:
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.
Yes, mmbase cvs code is all the zips files we currently have.
No, we are not extending mmbase.jar. We are creating something which
will help to let different customer systems look like the same. If they
look the same then it is easier to intergrate a component inside those
systems. When the systems look the same then it is easier to define
rules where components should adhere to.
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.
eh, yes that isn't smart, calling that we are going to build an mmbase
framework and then calling systems a framework too. The problem is that
the mentioned systems are not real customer systems. You have to
"configure" them to get a customer system.
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.
In my opinion you are solving two issue in development. Issue one is a
data management issue, because you want to store nodes. You use the
mmbase.jar for this to solve it which is, in my opinion, mmbase (we
never going to agree on this). Issue two is that you don't want to use
the api and like to script away. The solution for this is the
mmbase-taglib.jar. I have the same issues and use the same solutions for
it. I also have some other issues. So where is the other view?
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 ?
yes, preferably.
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.
My opinion again, it is not only the components method which was
blocking. It is also the blurr around which issues you can solve with
software which is developed by the MMbase community. The mmbase.org
website explains MMbase as a web content management system, but when you
get to know MMbase it is a mature data management engine with a lot of
ways to interact with it. MMbase solves an issue on a different level
then you would expect when you download it. Magnolia for example is more
on the level which is described on mmbase.org. With all the mmbase
binaries you can create the same thing as Magnolia and much more, but
you have to put some effort in it. I think mmbase as a data management
engine is very good and has many nice features. The taglib is a very
nice addition to it.
It is very confusing to me that two jars (mmbase.jar and
mmbase-taglib.jar) are actually one thing (mmbase?).
Of course I could be wrong on this, because I have never heard anybody
say that mmbase is a data management engine. It could also be that
nobody realized it.
Nico
_______________________________________________
Developers mailing list
[email protected]
http://lists.mmbase.org/mailman/listinfo/developers
