Stefano Mazzocchi wrote:
Guido Casper wrote:
Yes, I realized that flowscript is the perfect solution to the missing piece of the pyramid of contracts for the webapp space.
I just feel we should much more leverage it for this role and it is vital to give more emphasis to the user.
I'm wide open to proposals that help in this direction, Guido, because I'm 100% with you on this and if we are ruining the pyramid of contract with flowscript I want to know and I want to fix this as fast and painless as possible.
I continue to believe that cocoon.getComponent(role) within the real block framework is good enough for what we need.
But if you have a better idea, well, you know I'm always ready to throw stuff away when I see something better.
No, I don't have something better.
I believe that the ideas expressed within this thread (about differentiating between "internal" and "official" javadocs)
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105766229504616&w=2
(recently being pointed at by Unico)
are a perfect starting point.
<quote of="Sylvain">
We could then have a full javadoc, as of today, and a restricted "official API" javadoc, based on these @usage tags. This official API will also be far more lightweight and so less frightening for newcomers.
</quote>
This pretty much matches with Martin Fowlers notion of "published interfaces".
http://www.martinfowler.com/ieeeSoftware/published.pdf
<quote of="Fowler">
There's something to be said for the public-published distinction being more important than the more common public-private distinction.
</quote>
Once such a customized doclet mechanism is in-place (Does someone know wether QDox already has an Ant task? Or maybe we should use XDoclet for that?) it may easily be extended for "some kind of" flowscript-API.
are you volunteering? ;-)
-- Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
