On May 22, 2006, at 1:21 PM, Johannes Verelst wrote:
Hi all,
<mmbase-framework.zip>
point 3:
I like how it extends on the work already done in this area in 1.8
but there are no strickt rules in some areas that we now need to
enforce and creates some principles for. I do think several of the
points should include the ResourceLoader as its base. I would
personally don't mind to work more on this area since i have more
than a few projects in this format that need to be tuned a little
to be compliant i checked with michiel who is also willing to extend
his work in this area.
3,.1
Needs to explain the ResourceLoader and demand it in 3.2 on all file
access as a result. Someone should write down what seems
to be the accepted standard for dirs in applications/contribs fill in
the holes.
3.2
I personally don't agree people should be free to pick any
packagename, sofar we have pushed org.mmbase.applications.[name].*
maybe we need to discuss this but i don't feel leaving this free will
result in the best results. For example we might see packages
in non english names or that don't follow the java guidelines for
naming them. Also i think that it can result in weird effects for
example
someone starts a component called say 'magazines' and names it
nl.companyname.* puts in 1000lines of code then stops supporting it.
Others extend it to say 10000lines and a much more complete component
it that just ends up weird having the company name as part of
the package name (and lets not even start on name changes of
companies, takeovers, deaths of companies...).
3.3 We need to handle possible license and compile problems or
atleast make sure that makers are aware of their duties when they
include
external libs. Also i feel this should be done in combination with a
clear 'commons' area for MMbase 1.8, 1.9, 2.0 since it feels kind of
backwards
to have 20 mail.jars and activations.jars in each component and as a
result in our cvs (or sourceforce).
3.4 Im still unclear over if we need to create room for multiple sets
of html or types this was for example the reason i added templates/
jsp/ the 'jsp' part
since i expected more types to be possible (say flash) but this ended
up being confusing and since most people expect the templates/* dir
to be 1 on 1 with your html root. Example templates/jsp/mmbob i would
map to mmbob in your root not jsp/mmbob. Not a big issue but we need
to nail this down.
3.5 Great idea just to get i idea would that mean that each
component has its own web.xml in its jar ? that using the
ResourceLoader can be merged ? and using some tool that you run after
installing a new component (or at the end of your build process) ifso
why stop there ?
deploy mmbob web.xml
deploy mmbob html
deploy mmbob src
deploy mmbob documentation
3.6 im not against testing or jmeter tools im all for it but if you
'demand' a test for all the public methods does that mean we feel
each component also has a java api that needs to be stable ? The
question is why are other applications allowed to talk to it within
our idea of a framework?
3.7 no comments
3.8 no comments
3.9 extend the docbook idea and just like the web.xml merge create
some way using the ResourceLoader to parse them to html and pdf on
the fly so they are available on the system (like man pages)
3.10 I am clearly for option one all should be stand alone. But the
packaging project was a clear sign that people also want to be able
to build a 'compleet' webapp for a client and install it as such. So
i think both should be possible (not that hard) but by demanding
option one we limit dependencies.
4.0 to complex to talk about without a meeting but i do think each
component has its own model and this should be pushed more. Pierre/
Michiel/me already had a meeting about what might work since we
needed to fix some bugs in 1.8 around this issue. I fully agree that
combined with 4.1 and 4.2
we can't ignore this issue any longer
4.1 More and more it starting to sound to be like a interface type of
thing. I think we should just have a meeting pick a model and be done
with it but i do think there are more of these interfaces i know for
example submarine has worked on a 'shareable' objects for communities
maybe Ruud can talk a little about it. Don't want to make this more
complex but i can see a 'use' for having objects support subsets for
more reasons than just contentelements
4.2 good idea not sure how it will work out :)
5 Ive made my main point in the other mail, not creating one means we
will have many (i count atleast 6) do we define a reference
implementation
or some basic testing implementation as part of the mmbase distro.
5.1 I think this needs alot more work i still don't see how real
webpages that use multiple applications can be maintained in a good
way. This is probably me so a meeting on this would be nice. The
portlet method is one way but thats now not demanded anymore right ?
but somehow this
does need enough information to be used as a portlet right ? there
will all the meta information be ?
5,.2 no comments
5.3 this won't be easy, i do hope it will extend on what the portlets
concept allows found it to be a little limited, Also this point
probably means alot of rewriting of pages/code of people so we need
to make sure we get it right the first time and allow for a period to
slide over to this new model.
5.4 no comment except same point as in 5.0 this also means we atleast
need some basic tools in the distro for testing.
Greetings,
Daniel Ockeloen.
MMCoder
_______________________________________________
Developers mailing list
[email protected]
http://lists.mmbase.org/mailman/listinfo/developers
