RE: [RT] Use of flowscript or the pyramid of contracts (was Re:[RT] Checked exceptions considered harmful)
Stefano Mazzocchi <[EMAIL PROTECTED]> writes: > Hunsberger, Peter wrote: > > > Stefano Mazzocchi <[EMAIL PROTECTED]> writes: > > > > > > > >>Now we made it easier to write flowscript than to write > >>components, now > >>we have to focus on making it easier to write components than > >>flowscript. > >> > >>How? > >> > >>Chris' magic compiler classloader is the way to go, IMHO. > > > > > > If so, then it's going to have to work in all environments. It's > > still broken when deploying as an EAR under JBoss: > > > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27484 > > Fix it! ;-) > I spent some time trying to do just that. Got bogged down in finding the source for parts of Avalon and the Rhino stuff, and then there's the fact that it uses the Eclipse jdtcore libraries which I didn't even attempt to locate source for (I don't know if I'd need it). There is one heck of a lot of complex dependencies in that chunk of the code. However, I closed the bug; it turns out that upgrading to JBoss 3.2.3 makes the problem go away. I'd guess that Jboss EAR unwrapping was somehow interfering with Cocoons source resolving, but whether the bug is Jboss's or Cocoons's I don't know
Re: [RT] Use of flowscript or the pyramid of contracts (was Re:[RT] Checked exceptions considered harmful)
Hunsberger, Peter wrote: Stefano Mazzocchi <[EMAIL PROTECTED]> writes: Now we made it easier to write flowscript than to write components, now we have to focus on making it easier to write components than flowscript. How? Chris' magic compiler classloader is the way to go, IMHO. If so, then it's going to have to work in all environments. It's still broken when deploying as an EAR under JBoss: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27484 Fix it! ;-) -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
RE: [RT] Use of flowscript or the pyramid of contracts (was Re:[RT] Checked exceptions considered harmful)
I got stuck trying to figure why a URLsource was coming back and just ended up disabling the code. I suspect that JBoss must wrap the EAR file in some way so that request to read the files contained within it can be returned to the servlet container (Tomcat in our case). Running Cocoon under JBoss is pretty easy; install one of the combined JBboss/Tomcat packages off the web site, make a WAR or EAR out of Cocoon, drop it into the deploy directory and away it goes... I'll try doing some more debugging but the code is pretty opaque from my perspective and I don't have a lot of time to look at the problem. > -Original Message- > From: Christopher Oliver [mailto:[EMAIL PROTECTED] > Sent: Friday, April 23, 2004 10:49 AM > To: [EMAIL PROTECTED] > Subject: Re: [RT] Use of flowscript or the pyramid of > contracts (was Re:[RT] Checked exceptions considered harmful) > > > There's not enough information in that bug report to determine the > problem. Can you try to debug why a URLSource (with exists() > == true) is > being returned by the source resolver for the (presumably > nonexistent) > resource "org.java"? > > I had no luck debugging this since I can't recreate the > problem (I don't > use JBoss) and because I have no idea where to find the > source code for > the classes in excalibur-sourceresolve-1.1.jar. Anyone know > where that > is? I browsed the avalon cvs but couldn't find it. > > Regards, > > Chris > > Hunsberger, Peter wrote: > > >Stefano Mazzocchi <[EMAIL PROTECTED]> writes: > > > > > > > > > >>Now we made it easier to write flowscript than to write > >>components, now > >>we have to focus on making it easier to write components than > >>flowscript. > >> > >>How? > >> > >>Chris' magic compiler classloader is the way to go, IMHO. > >> > >> > > > >If so, then it's going to have to work in all environments. > It's still > >broken when deploying as an EAR under JBoss: > > > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27484 > > > > > > > > > > > > > > >
Re: [RT] Use of flowscript or the pyramid of contracts (was Re:[RT] Checked exceptions considered harmful)
There's not enough information in that bug report to determine the problem. Can you try to debug why a URLSource (with exists() == true) is being returned by the source resolver for the (presumably nonexistent) resource "org.java"? I had no luck debugging this since I can't recreate the problem (I don't use JBoss) and because I have no idea where to find the source code for the classes in excalibur-sourceresolve-1.1.jar. Anyone know where that is? I browsed the avalon cvs but couldn't find it. Regards, Chris Hunsberger, Peter wrote: Stefano Mazzocchi <[EMAIL PROTECTED]> writes: Now we made it easier to write flowscript than to write components, now we have to focus on making it easier to write components than flowscript. How? Chris' magic compiler classloader is the way to go, IMHO. If so, then it's going to have to work in all environments. It's still broken when deploying as an EAR under JBoss: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27484
RE: [RT] Use of flowscript or the pyramid of contracts (was Re:[RT] Checked exceptions considered harmful)
Stefano Mazzocchi <[EMAIL PROTECTED]> writes: > > Now we made it easier to write flowscript than to write > components, now > we have to focus on making it easier to write components than > flowscript. > > How? > > Chris' magic compiler classloader is the way to go, IMHO. If so, then it's going to have to work in all environments. It's still broken when deploying as an EAR under JBoss: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27484
Re: [RT] Use of flowscript or the pyramid of contracts (was Re: [RT] Checked exceptions considered harmful)
Stefano Mazzocchi wrote: Daniel Fagerstrom wrote: [snip very nice argumentation] WDYT? I agree with Daniel: +1 for simple input modules, -1 for complex abstract ones. I totally agree too. +1 I'll rest my case on the input modules, but we should try to make an effort to discouradge people from getting wildly over-functional with them. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [RT] Use of flowscript or the pyramid of contracts (was Re:[RT] Checked exceptions considered harmful)
Stefano Mazzocchi wrote: Leszek Gawron wrote: Components are existed before Flow, but Flow is more popular than writing components, the question is why? flowscript + notepad vs. components + eclipse. and the winner concerning development lifecycle time is: flowscript. Flowscript is: a) scripted b) automatically reloaded by cocoon after changes without container restart. See? *this* is what I'm talking about. Now we made it easier to write flowscript than to write components, now we have to focus on making it easier to write components than flowscript. How? Chris' magic compiler classloader is the way to go, IMHO. From a users point of view: YES YES YES. I am now porting an application from pure flowscript to Java since I got a headache from looking at the 1000+ lines, 4000+ words flowscript based app. And this was only the framework for the business logic:) The reason I did this was actually because I didn't want my WEB-INF classes with application specific classes. And re-starting each time I test is also not preferred. I think if the compiler/classloader would have existed for flowscript I would just use that, as Java is very much simpler to develop and maintain. I think though, that some formal properties of a component (what makes a component a component) should be defined. A bit like the way JavaBeans are defined: A java bean has ...). Leon Given a choice, people would like to use eclipse for their business logic, I'm sure, give them autocompletion and autoreload and logic will start floating from flow to components. keep in mind that with real blocks any class is a component, so no reason to implement the avalon lifecycle if you don't want to.
Re: [RT] Use of flowscript or the pyramid of contracts (was Re: [RT] Checked exceptions considered harmful)
Tim Olson wrote: you theoreticians seem all too willing to break production systems to enforce your latest notion of best practices. we "theoreticians" wouldn't have given you the things that you are using right now and that you are happy with. btw, this is an open community and open to criticism, so if you want, just make a proposal and we'll discuss it. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [RT] Use of flowscript or the pyramid of contracts (was Re: [RT] Checked exceptions considered harmful)
Daniel Fagerstrom wrote: [snip very nice argumentation] WDYT? I agree with Daniel: +1 for simple input modules, -1 for complex abstract ones. I'll rest my case on the input modules, but we should try to make an effort to discouradge people from getting wildly over-functional with them. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [RT] Use of flowscript or the pyramid of contracts (was Re:[RT] Checked exceptions considered harmful)
Leszek Gawron wrote: On Sun, Apr 18, 2004 at 06:46:41PM -0600, Antonio Gallardo wrote: Guido Casper dijo: I think that cocoon.getComponent(role) would be enough if writing those components would be as painless as writing flowscript. No need for more complex stuff. I don't think developers aren't eager to write reusable components. But currently it's just that hard to come up with components really making the user's life easier. Yep. One of the things that refrained us to write components is the too much overhead they have: 1-Implementations of the lifecycle: Configurable, composable, etc. 2-The (1) give you even more code to write based on the implementations you choosed in (1). And people just want to write a simple hello wold component. The question is how much lines I need to write. And when we realize it is more than 20 lines. We are lost. It is really the better way to do things? I think the key is in KISS. The Flow Engine is so popular because of his own simplicity. And that is cool. I realize that components are a diferents than FlowEngine scripts. But I try to sell the concept of easy components writing is what the users need. An alert is already out: People is starting to (ab)use of FlowEngine code because they feel it is easier to write the full logic on FlowEngine instead of writing a component. I think we need think about this fact. On the mail list are clear samples of how they are even making workarounds to make things works in Flow at any cost, even when using a component will be easier (you have full access to many thins and in flow you have not the same access). But the perception win in this case. Components are existed before Flow, but Flow is more popular than writing components, the question is why? flowscript + notepad vs. components + eclipse. and the winner concerning development lifecycle time is: flowscript. Flowscript is: a) scripted b) automatically reloaded by cocoon after changes without container restart. See? *this* is what I'm talking about. Now we made it easier to write flowscript than to write components, now we have to focus on making it easier to write components than flowscript. How? Chris' magic compiler classloader is the way to go, IMHO. Given a choice, people would like to use eclipse for their business logic, I'm sure, give them autocompletion and autoreload and logic will start floating from flow to components. keep in mind that with real blocks any class is a component, so no reason to implement the avalon lifecycle if you don't want to. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [RT] Use of flowscript or the pyramid of contracts (was Re:[RT] Checked exceptions considered harmful)
Antonio Gallardo wrote: > I will add I will prefer to change the default FlowEngine language from javascript to Groovy. I really believe it will give the user a more productive language with the best Java integration. It will be really a good tradeoff. This does exactly in the wrong direction. We should *not* make it easier for people to write flowscript, we should make it easier for people to write components for their business logic and not pollute the flow logic with it. In the pyramid of contracts, sitemap + flow reside in the "administration" concern island, while business logic components reside in the "logic" concern island. If you make it easier for people to write java in flow, they will start blurring this contract and the whole cocoon idea falls apart. This is the concern that Gianugo and Guido expressed and I completely agree with them on this. Please, if we loose SoC cocoon will become a mess. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [RT] Use of flowscript or the pyramid of contracts (was Re:[RT] Checked exceptions considered harmful)
Antonio Gallardo wrote: Can Cocoon live beyond Java? Cocoon life depend on Java? I'm in crete right now. Visiting ruins of 3000 years ago make you understand how futile questions like these really are. If it works, use it, if not try to fix it, if you can't fix it, let go and use something else. It's a simple as that. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [RT] Use of flowscript or the pyramid of contracts (was Re: [RT] Checked exceptions considered harmful)
Guido Casper wrote: Leon Widdershoven wrote: Guido Casper wrote: Yes that might be one reason. Another one IMO is that it's much easier to (conceptually) come up with a reusable sitemap component (being a specialized thing) than it is to come up with a reusable flow component. Guido I think that is the true question. I am writing an application which gets an excel spreadsheet with information; this information must be read into data structures, and compared with existing databaserecords, and then merged. I use flow to get the user data. I have tried to write the total application entirely in Javascript (with of course HSSF Java classes). It works, but is not really maintable. So I wrote a reusable flow component called a Java Package. The main class gets the uploaded spreadsheet and all flags, and returns errors or OK. It can be called from any flowscript program, the classes can be configured, it can be called by Java classes. How much more reusable can you get? And at the same time I think this is not what flowscript developers call reusable. What is the characteristic of a reusable flowscript component, defined in a way a user can understand? For cocoon components that's easy. Implement a particular interface and it is a particular kind of component. But flowscript is just much more free on the one side, and in other ways a bit more restricted. But it is possible :-), like somewhat being proved by CForms (and other components as well but CForms is the only one with a dedicated flowscript API). I'm quite excited about the recent discussions about the "best" database interaction layer. It may result in several approaches in parallel (which is perfect as there are quite various requirements being targeted by db apps/tools) but I feel one (or several) of those might evolve into something like a "prototype of a reusable flow component" (or be the base of another layer providing the "prototype of a reusable flow component" :-). Guido Me too. I do hope that more than one way of doing things will be created. There is nothing like darwinism to determine what is really usefull. Besides, the Object/Relational mapping can also be done in (at least) two ways. I even saw a listing of about 9 Java O/R frameworks! Some free, some not. I think Hibernate and OJB are the most probable "early adopters", though OJB withJDO has a bit of a disadvantage since the required libraries cannot -apparently - be bundled with cocoon but must be downloaded by sun, which is a bit of a set-back concerning the samples block. I however do look forward to an O/R framework with javascript, besides a simple SQL engine, of course. I have started playing with O/R myself as I found it both easier to understand (a single framework is an advantage), and found better understandable documentation on it. It helped that my reverse-db of OJB tool did not work out of the box (as a typical user who earns his meager(:) bread with development I do like non-core (for me) functionality to work out of the box). Leon
Re: [RT] Use of flowscript or the pyramid of contracts (was Re: [RT] Checked exceptions considered harmful)
Leon Widdershoven wrote: Guido Casper wrote: Yes that might be one reason. Another one IMO is that it's much easier to (conceptually) come up with a reusable sitemap component (being a specialized thing) than it is to come up with a reusable flow component. Guido I think that is the true question. I am writing an application which gets an excel spreadsheet with information; this information must be read into data structures, and compared with existing databaserecords, and then merged. I use flow to get the user data. I have tried to write the total application entirely in Javascript (with of course HSSF Java classes). It works, but is not really maintable. So I wrote a reusable flow component called a Java Package. The main class gets the uploaded spreadsheet and all flags, and returns errors or OK. It can be called from any flowscript program, the classes can be configured, it can be called by Java classes. How much more reusable can you get? And at the same time I think this is not what flowscript developers call reusable. What is the characteristic of a reusable flowscript component, defined in a way a user can understand? For cocoon components that's easy. Implement a particular interface and it is a particular kind of component. But flowscript is just much more free on the one side, and in other ways a bit more restricted. But it is possible :-), like somewhat being proved by CForms (and other components as well but CForms is the only one with a dedicated flowscript API). I'm quite excited about the recent discussions about the "best" database interaction layer. It may result in several approaches in parallel (which is perfect as there are quite various requirements being targeted by db apps/tools) but I feel one (or several) of those might evolve into something like a "prototype of a reusable flow component" (or be the base of another layer providing the "prototype of a reusable flow component" :-). Guido -- Guido Casper - S&N AG, Competence Center Open Source Tel.: +49-5251-1581-87 Klingenderstr. 5mailto:[EMAIL PROTECTED] D-33100 Paderborn http://www.s-und-n.de -
RE: [RT] Use of flowscript or the pyramid of contracts (was Re: [RT] Checked exceptions considered harmful)
Daniel Fagerstrom <[EMAIL PROTECTED]> writes: > > Hunsberger, Peter wrote: examples > > > So, lets see, I started with a 7 line sitemap snippet, where > most Cocoon > users should be able to understand at a course level what is going on > after short look at it. Then I proposed that the flowscript version > where you have to look at two files at once for seeing what > is going on > is more complicated to grasp. And now you propose that it would have > been better to write something that abstracts away about > everything that > was concrete and easy to grasp about the first example. I moved any explicit handling of the page to the flowscript, instead of looking in the sitemap you now look in the flowscript. I also added some generic handling for any page that does not need specific handling. That's something you can already do with the site map independent of flow. So, I added more capability, but I don't think I abstracted anything or made it harder to understand. Surely, you're not suggesting that the average person manipulating a Cocoon sitemap can't understand that * is a wild card? abstraction discussion > > In our case, we just have a > >whole patch of common parameters we always pass in the > sitemap, subbing > >them in via an action, but that's more-or-less the same > thing as using > >a module to get at them...) > > > Sure, you can do that, but you either have to turn of caching or make > the cache key depend on a lot of stuff that it shouldn't > depend on. Also > after having started to feed my xslt with params explicitly through > input-modules in the sitemap to get better cache control I also, as a > side effect, find it easier to understand what my apps do > from looking > at the sitemap. Umm, there should be no difference if the parameter in the sitemap is generated from an action or a module? But, I'm not arguing against modules (I quite like some of them), but rather in favor of moving flow control out of the sitemap (and using flow script). > Request attributes are often parts of the urls and because of that a > part of the sitemaps concern area. Also flow attributes are > part of the > contract between the sitemap and flow scripts, so in many cases it, > IMHO, increase readability if you are explicit about what flowscript > attributes a sitemap rule depends on. Hmm, I like the sitemap purely to specify how things are generated. There can be a lot of communication between components to precisely specify what needs to be generated, but as much as possible I try to keep communication between flow and sitemap minimized. > >If you're site map shrinks down to almost nothing, and all > the logic on > >what page is being called is in the flow script, doesn't that add > >clarity? In your example, you're still using the sitemap to > determine > >page flow... > > > > > IMO, the sitemap contains excelent abstractions for > describing one page > "page flows", as long as you don't require to much input > handling, (and > as some readers might remember, I have some ideas about how > to improve > the sitemap abilities in that area as well ;) ). > > And flowscrips are a good abstraction of multipage flow. IMO > it does not > increase readability to put absttractions of one page access > patterns, > this is of course a matter of taste. If you're just generating a couple of pages I think I can agree with you. But if you're just generating a couple of pages I'm not sure why you are using Cocoon in the first place? In our case, we have over 350 different pages being generated on the production system, with 1000's more to come...
RE: [RT] Use of flowscript or the pyramid of contracts (was Re: [RT] Checked exceptions considered harmful)
Leon Widdershoven <[EMAIL PROTECTED]> writes: > > > I don't see much difference between marking something "private" vs. > > "not for normal access by end users"? In fact I think the > "RAD flag" > > would be a little more liberal than private vs. public since if you > > needed you could always flag a script as using non-FOM > objects, but if > > the object is private you're going to need the source of the Java > > object to make the change? > > It is not the flag in itself, it is the reason why you would > apply it. private as in Java or C++ is used in general for > internal helper functions. They tend to be very > implementation dependent. A component that really does > something also tends to have implementation specific > functions. And I do not think it's bad if they stay hidden > just *because* their contract tends to fluctuate over > versions. So removing them from the namespace is to protect > the user. And in that sense - if a function is private, you'd > not want other objects to play with the component internals - > at all. It may break the component. > > But it really could be that I misunderstood things. I > understood that developers would make only a portion of the > interface available to users, and another portion to > developers. That seems quite artificial. Flagging a function > needs to have a clear meaning, one readily understood by even > the simplest of users (e.g. me). Strong potential to damage > your environment, or your objects, as a side effect is > something even I can understand. I wasn't thinking of anything that granular, just an all or nothing switch; script X can or cannot access things outside the FOM... > Maybe I can give a small example: > You have a component which can transform a given string into > a Base64 encoded, MD5 transformed String. An implementer > could just provide the user interface (non-flagged) String > convert(String). And hide the utility functions Byte[] > md5(Byte[]), String Base64(Byte[]). That would be a shame > since then everyone needing a Base64 would have to roll their > own (or, in my case, copy-paste from the component source). > > The example is a bit artificial, and the syntax is disturbingly Java > like:) but javascript does just not have the clear > expressions to demonstrate what I want. > > On a side note: is it possible to split your javascript file > into multiple files, each holding a class-like thingy and > integrate them in the main flowscript, using e.g. cocoon.load( uri )? Not sure quite what your asking or if it is possible...??
Re: [RT] Use of flowscript or the pyramid of contracts (was Re: [RT] Checked exceptions considered harmful)
Hunsberger, Peter wrote:
Daniel Fagerstrom <[EMAIL PROTECTED]> writes:
I believe OTH that some of the "simpler" input modules,
especially the
request module, the request attribute module and the flow attribute
module, makes it possible to have a *cleaner* SOC, than it is
possible
without them. Let me give a simple example:
I fail to see that:
sortOrder.js:
function getSortOrder() {
sendPage("table-view",
{"sortOrder": cocoon.request.attibute.sortOrder}
}
would be an improvement in clearity compared to using input modules,
Ok, but what I think you are partly missing is the level of generic
sitemap that flow can allows. Instead it becomes something more like:
controller.js:
function main( page ){
var func = this[ page ];
var args = new Array( page );
if ( func != undefined )
{
func.apply( this, args );
}
else
sendPage( "_page.+page );
}
function table( page ) {
sendPage("_page."+ page,
{"sortOrder": cocoon.request.attibute.sortOrder}
}
So, lets see, I started with a 7 line sitemap snippet, where most Cocoon
users should be able to understand at a course level what is going on
after short look at it. Then I proposed that the flowscript version
where you have to look at two files at once for seeing what is going on
is more complicated to grasp. And now you propose that it would have
been better to write something that abstracts away about everything that
was concrete and easy to grasp about the first example.
Let me discuss a little bit about abstractions. First I also have a CS
background and I love abstractions. But some of my coworkers whithout
such background are less than happy when they try to support apps that I
have written, where I excess in abstractions. And to be honest,
sometimes when I go back to old apps that I have written I am less happy
whith the use of abstractions my self, it often takes much longer to
understand whats going on. So my coding style has become less abstract
when it once was.
Some rule of thumb that I use is: don't abstract anything before you
have at least three examples of it. Here refactoring style programming
has helped me a lot. Start simple and _if_ common concepts appears
factor out them, don't try to do that upfront. When writing sitemaps I
try to make them be a map of the site rather than a collection of
abstracted access patterns.
I think you have to do some kind of cost/benefit analysis before you
introduce an abstraction. How long time will it take to develop, how
long time will it take to understand for your coworkers, and for
yourself when you return to the code after a year. And how much time
will it save. I would guess that the "cost" for your sitemap and
flowcript snippet would be at least a order of magnitude higher than for
the first one, (this is of course highly dependent on what design
patterns that you currently use, background and so on). So you would
need a lot of regularity in your app before it is worthwhile.
There is one kind of abstraction that we can call "leaky abstraction"
that IMO is especially expensive, and unfortionlly the easisest ones to
come upp with. Leaky abstractions are such abstractions where the
deatils from the layer beneath, leaks through so that you have to
understand booth levels at once. While good abstractions are so well
thought out concepts so that you don't need to now anything about the
layer underneath.
(I believe making the generic XSLT processor handle the flow generated
parameters directly wouldn't be that hard?
Not hard at all, before the arive of input modules we maintained an own
fork of the xslt transformer that got some extra stuff as input to the
xslt params.
In our case, we just have a
whole patch of common parameters we always pass in the sitemap, subbing
them in via an action, but that's more-or-less the same thing as using a
module to get at them...)
Sure, you can do that, but you either have to turn of caching or make
the cache key depend on a lot of stuff that it shouldn't depend on. Also
after having started to feed my xslt with params explicitly through
input-modules in the sitemap to get better cache control I also, as a
side effect, find it easier to understand what my apps do from looking
at the sitemap.
Request attributes are often parts of the urls and because of that a
part of the sitemaps concern area. Also flow attributes are part of the
contract between the sitemap and flow scripts, so in many cases it,
IMHO, increase readability if you are explicit about what flowscript
attributes a sitemap rule depends on.
If you're site map shrinks down to almost nothing, and all the logic on
what page is being called is in the flow script, doesn't that add
clarity? In your example, you're still using the sitemap to determine
page flow...
IMO, the sitemap co
Re: [RT] Use of flowscript or the pyramid of contracts (was Re: [RT] Checked exceptions considered harmful)
But both such cases would be to protect the user, and not to force users to a certain development model favoured by the developer. The developer may well be right in his opinions, but users come from different backgrounds and would not understand they be limited because their way is not neat. I am sorry if this sounds to harsh, but it really *is* hard enough to find functions which do what you want them to do. If you then find out those functions are blocked for some unfathomable (ideologic) reason, you would not be glad. Well, given the fact that I wrote the bit you're responding to and not Guido I don't think he'll find it harsh ;-) Oops -- Sorry Guido:) I don't see much difference between marking something "private" vs. "not for normal access by end users"? In fact I think the "RAD flag" would be a little more liberal than private vs. public since if you needed you could always flag a script as using non-FOM objects, but if the object is private you're going to need the source of the Java object to make the change? It is not the flag in itself, it is the reason why you would apply it. private as in Java or C++ is used in general for internal helper functions. They tend to be very implementation dependent. A component that really does something also tends to have implementation specific functions. And I do not think it's bad if they stay hidden just *because* their contract tends to fluctuate over versions. So removing them from the namespace is to protect the user. And in that sense - if a function is private, you'd not want other objects to play with the component internals - at all. It may break the component. But it really could be that I misunderstood things. I understood that developers would make only a portion of the interface available to users, and another portion to developers. That seems quite artificial. Flagging a function needs to have a clear meaning, one readily understood by even the simplest of users (e.g. me). Strong potential to damage your environment, or your objects, as a side effect is something even I can understand. Maybe I can give a small example: You have a component which can transform a given string into a Base64 encoded, MD5 transformed String. An implementer could just provide the user interface (non-flagged) String convert(String). And hide the utility functions Byte[] md5(Byte[]), String Base64(Byte[]). That would be a shame since then everyone needing a Base64 would have to roll their own (or, in my case, copy-paste from the component source). The example is a bit artificial, and the syntax is disturbingly Java like:) but javascript does just not have the clear expressions to demonstrate what I want. On a side note: is it possible to split your javascript file into multiple files, each holding a class-like thingy and integrate them in the main flowscript, using e.g. cocoon.load( uri )? If I read to much in the statement above I am sorry. But I strongly feel that flow is a more powerfull technology than xsp for many applications, and that it should be kept simple for users. And simple is not a limited set of functions, but a feature rich environment which allows you to do what you want without to much Java (a bit like xsp is now), Personally, I tend to agree. However, if others feel the need to restrict the contract more than currently I think there should be some kind of escape hatch for developers... The developer writes the code. The developer owns the code. He or she can do with it what he or she likes. Fortunately, the people who write code for Cocoon seem to be very user-oriented (apart from naturally striving to elegant solutions which is I think quite common to all people who write software), so I'm quite confident that in the end all restrictions placed by developers will truly make sense. I just hope that that sense of the restriction translates into documentation in the source (yes - I do read the source. Grep and find are among my best friends:) Leon
RE: [RT] Use of flowscript or the pyramid of contracts (was Re: [RT] Checked exceptions considered harmful)
Leon Widdershoven <[EMAIL PROTECTED]> writes: > > Guido Casper wrote: > > > Yes that might be one reason. Another one IMO is that it's > much easier > > to (conceptually) come up with a reusable sitemap component > (being a > > specialized thing) than it is to come up with a reusable flow > > component. > > > > Guido > > > I think that is the true question. > I am writing an application which gets an excel spreadsheet with > information; > this information must be read into data structures, and compared with > existing > databaserecords, and then merged. I use flow to get the > user data. I have tried to write the total application > entirely in Javascript (with of > course HSSF > Java classes). It works, but is not really maintable. > So I wrote a reusable flow component called a Java Package. > The main class gets the uploaded spreadsheet and all flags, > and returns errors or OK. It can be called from any > flowscript program, the classes can be configured, it can be > called by Java classes. How much more reusable can you get? > > And at the same time I think this is not what flowscript > developers call reusable. What is the characteristic of a > reusable flowscript component, defined in a way a user can > understand? For cocoon components that's easy. Implement a > particular interface and it is a particular kind of > component. But flowscript is just much more free on the one > side, and in other ways a bit more restricted. > > > >> > >> I think you could slowly move towards enforcing a FOM only > access to > >> Cocoon; maybe start with two levels of access: a default > FOM only and > >> a "RAD flag" (developer_mode='true') that be configured to say to > >> Cocoon that a developer wants to allow script X to have access > >> outside of the FOM model ? > >> > No, please no. It is hard enough to find components/scripts that do > what you > want them to do - without reinventing the wheel. It really is > not a good > idea > to artificially limit access to ready-made logic and thus > forcing users > to either > hack the cocoon sources, or to reinvent the wheel. > > What you can say is that particular scripts should be > considered private > or protected > to indicate that their contract may change at any time without notice > and that it > is thus very unwise to build a system based on that. (Yes, like Java). > > A protected script also makes sense if it manages a resource > which must > be called > only when particular demands have been met, or which may have side > effects on the > fllowscript environment. > > But both such cases would be to protect the user, and not to > force users to a certain development model favoured by the > developer. The developer may well be right in his opinions, > but users come from different backgrounds and would not > understand they be limited because their way is not neat. > > I am sorry if this sounds to harsh, but it really *is* hard enough to > find functions which > do what you want them to do. If you then find out those functions are > blocked for > some unfathomable (ideologic) reason, you would not be glad. Well, given the fact that I wrote the bit you're responding to and not Guido I don't think he'll find it harsh ;-) I don't see much difference between marking something "private" vs. "not for normal access by end users"? In fact I think the "RAD flag" would be a little more liberal than private vs. public since if you needed you could always flag a script as using non-FOM objects, but if the object is private you're going to need the source of the Java object to make the change? > > If I read to much in the statement above I am sorry. But I > strongly feel > that flow > is a more powerfull technology than xsp for many > applications, and that it should be kept simple for users. > And simple is not a limited set of > functions, but > a feature rich environment which allows you to do what you > want without > to much > Java (a bit like xsp is now), Personally, I tend to agree. However, if others feel the need to restrict the contract more than currently I think there should be some kind of escape hatch for developers...
Re: [RT] Use of flowscript or the pyramid of contracts (was Re: [RT] Checked exceptions considered harmful)
Guido Casper wrote: Yes that might be one reason. Another one IMO is that it's much easier to (conceptually) come up with a reusable sitemap component (being a specialized thing) than it is to come up with a reusable flow component. Guido I think that is the true question. I am writing an application which gets an excel spreadsheet with information; this information must be read into data structures, and compared with existing databaserecords, and then merged. I use flow to get the user data. I have tried to write the total application entirely in Javascript (with of course HSSF Java classes). It works, but is not really maintable. So I wrote a reusable flow component called a Java Package. The main class gets the uploaded spreadsheet and all flags, and returns errors or OK. It can be called from any flowscript program, the classes can be configured, it can be called by Java classes. How much more reusable can you get? And at the same time I think this is not what flowscript developers call reusable. What is the characteristic of a reusable flowscript component, defined in a way a user can understand? For cocoon components that's easy. Implement a particular interface and it is a particular kind of component. But flowscript is just much more free on the one side, and in other ways a bit more restricted. I think you could slowly move towards enforcing a FOM only access to Cocoon; maybe start with two levels of access: a default FOM only and a "RAD flag" (developer_mode='true') that be configured to say to Cocoon that a developer wants to allow script X to have access outside of the FOM model ? No, please no. It is hard enough to find components/scripts that do what you want them to do - without reinventing the wheel. It really is not a good idea to artificially limit access to ready-made logic and thus forcing users to either hack the cocoon sources, or to reinvent the wheel. What you can say is that particular scripts should be considered private or protected to indicate that their contract may change at any time without notice and that it is thus very unwise to build a system based on that. (Yes, like Java). A protected script also makes sense if it manages a resource which must be called only when particular demands have been met, or which may have side effects on the fllowscript environment. But both such cases would be to protect the user, and not to force users to a certain development model favoured by the developer. The developer may well be right in his opinions, but users come from different backgrounds and would not understand they be limited because their way is not neat. I am sorry if this sounds to harsh, but it really *is* hard enough to find functions which do what you want them to do. If you then find out those functions are blocked for some unfathomable (ideologic) reason, you would not be glad. If I read to much in the statement above I am sorry. But I strongly feel that flow is a more powerfull technology than xsp for many applications, and that it should be kept simple for users. And simple is not a limited set of functions, but a feature rich environment which allows you to do what you want without to much Java (a bit like xsp is now), Leon
RE: [RT] Use of flowscript or the pyramid of contracts (was Re: [RT] Checked exceptions considered harmful)
> > we already have a nice system of flow helper methods to > access entity beans > > and pump them into XML. we use flow to select which > components are needed > > when, and the contract with our GUI designers is XML. we > were already burnt > > quite badly when sendPage() became a requirement, since we > were using flow > > to merely select actions and the sitemap had all of our > branching. we are > > now unable to upgrade past 2.1.2 without major refactoring > which honestly we > > can't afford to do. > > you theoreticians seem all too willing to break production > systems to > > enforce your latest notion of best practices. > > Tim, don't take the word for everything said in a RT thread and don't > worry that access to Java will be disabled in the 2.x branch > (if ever) > as this certainly would break any production system running > on with flow. sorry to be so sensitive. i still have a bad taste from the exception being thrown if no sendPage() is present.
Re: [RT] Use of flowscript or the pyramid of contracts (was Re: [RT] Checked exceptions considered harmful)
Tim Olson wrote: Yes, we habe FOM. The difference to the sitemap is that the sitemap enforces the contract while flow doesn't. One drastic approach would be to stop flow from being able to access java at all, if not thru FOM. I would be in favor of that once we have the real block system running, but at that point it might well be too late. we already have a nice system of flow helper methods to access entity beans and pump them into XML. we use flow to select which components are needed when, and the contract with our GUI designers is XML. we were already burnt quite badly when sendPage() became a requirement, since we were using flow to merely select actions and the sitemap had all of our branching. we are now unable to upgrade past 2.1.2 without major refactoring which honestly we can't afford to do. you theoreticians seem all too willing to break production systems to enforce your latest notion of best practices. Tim, don't take the word for everything said in a RT thread and don't worry that access to Java will be disabled in the 2.x branch (if ever) as this certainly would break any production system running on with flow. Guido -- Guido Casper - S&N AG, Competence Center Open Source Tel.: +49-5251-1581-87 Klingenderstr. 5mailto:[EMAIL PROTECTED] D-33100 Paderborn http://www.s-und-n.de -
Re: [RT] Use of flowscript or the pyramid of contracts (was Re: [RT] Checked exceptions considered harmful)
Hunsberger, Peter wrote: Guido Casper <[EMAIL PROTECTED]> writes: As I alway try to keep my flowscript as "exception-handling-free" as possible and as I feel that this sentiment is not shared by everyone, I thought it is a good oportunity to come up with another concern. Hope it's OK to steal this thread. Antonio Gallardo wrote: Hi Ugo: I understand that "time" is a good teacher. Things that now are easy,some years ago was not. Building the first path is the worse task. And since programming is a very dynamic beast, where what yesterday was the "best and recommended by the gurus", today "the same gurus tell you that this is totally wrong". Yes, not only the gurus' opinions changed but "things" changed. I keep on wondering wether it just takes time to build best practices or best practices are really constantly changing. If I could choose between constantly adjusting best practices or seeking for a long term strategy I would (obviously) opt for the latter. I'm not sure what would be best for Cocoon though (probably doing both). I think there is something else going on here also: as technologies mature there is a push to make them more accessible. Making them more accessible means adding in capabilities that don't require formal CS training. JavaScript and scripting languages in general are a good example of this. They enable a whole new level of accessibility for a whole new audience that wants to "just do it" and have never heard of best practices. This is good, the demand for such a level of capability means a product has reached a level of appeal where even non CS users are wanting to use it. As such, we shouldn't be surprised if some of the uses for these capabilities don't employ what a more traditional Cocoon developer would consider best practices. So, my high level advice would be not to try and control such experimentation too much. Watch and see what comes of it and then start to develop a new level of best practices. Cforms is an example of this; the community in general is still working to figure out what is best practices for cforms: how to bind, how to add action handlers, etc. There's a general picture emerging, but it's not clear (as an outside observer) exactly what parts of cforms embody Cocoon flow best practices yet. I think this will become much clearer over time. So, I think, yes, you can have both strategy and best practices but it's just going to take time for the best practices to emerge and having a strategy on how to guide that will help (if we really understand what the strategy will do). The pattern to apply might be to seperate the things changing from the things staying the same. Recognizing what stays the same and what might change requires exerience as well. But the Cocoon community should have some experience in that space as what should stay the same IMO is the desire to separate the concerns and to keep the pyramid of contracts. Welcome to my first RT :-) Gee, I have RT all the time, I just never write them down ;-)... Well, OK ... I do have ... hmm ... point taken :-) From the arrival of flow I liked it very much. But at the same time I felt it weakens the pyramid of contracts to a great extent (as Gianugo recently pointed out as well). The pyramid of contracts defined several roles, but what made it so powerful (IMO) was the strong contract between a user and a developer of Cocoon. I feel like the distinction between these two not being that clear anymore. It may be not immediately clear what this distinction is and I thought a lot about it (and my opinion on this may be debatable). So here it goes: "A user is someone building applications without writing a single line of Java code." Some people might argue: Hm, if you try to build your application without writing any Java code you end up in a mess. But the point of the above is, if that user needs a component written/extended in Java he can go to "his" developer and tell him: Go off and build this component for me and come back when you're done. When this developer comes back with the ready-built component the user goes on finishing his app. This is a strong contract. An important detail that easily slips through is the fact that it is the user being responsible for the application's architecture not the developer. So one might come up with the most simple definition of a Cocoon user as "someone building Cocoon apps without having eclipse installed" (Idea and JBuilder counts as well - but Emacs doesn't :-). With flow this distinction is not that clear anymore. I think the line has always been blurred (does a user modify the sitemap?), Well, yes. It's the _user_ building the application. The line may not be always crystal clear. But the point is that it allows you to separate concerns. And even if it's always myself wearing a developer hat or wearing a user hat it surely makes complex applications more manageable and gives me a d
RE: [RT] Use of flowscript or the pyramid of contracts (was Re: [RT] Checked exceptions considered harmful)
Daniel Fagerstrom <[EMAIL PROTECTED]> writes:
> I believe OTH that some of the "simpler" input modules,
> especially the
> request module, the request attribute module and the flow attribute
> module, makes it possible to have a *cleaner* SOC, than it is
> possible
> without them. Let me give a simple example:
>
>
>
>
>
>
>
>
>
>
> I fail to see that:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> sortOrder.js:
>
> function getSortOrder() {
>sendPage("table-view",
> {"sortOrder": cocoon.request.attibute.sortOrder}
> }
>
> would be an improvement in clearity compared to using input modules,
Ok, but what I think you are partly missing is the level of generic
sitemap that flow can allows. Instead it becomes something more like:
controller.js:
function main( page ){
var func = this[ page ];
var args = new Array( page );
if ( func != undefined )
{
func.apply( this, args );
}
else
sendPage( "_page.+page );
}
function table( page ) {
sendPage("_page."+ page,
{"sortOrder": cocoon.request.attibute.sortOrder}
}
(I believe making the generic XSLT processor handle the flow generated
parameters directly wouldn't be that hard? In our case, we just have a
whole patch of common parameters we always pass in the sitemap, subbing
them in via an action, but that's more-or-less the same thing as using a
module to get at them...)
If you're site map shrinks down to almost nothing, and all the logic on
what page is being called is in the flow script, doesn't that add
clarity? In your example, you're still using the sitemap to determine
page flow...
RE: [RT] Use of flowscript or the pyramid of contracts (was Re: [RT] Checked exceptions considered harmful)
> > Yes, we habe FOM. The difference to the sitemap is that the sitemap > > enforces the contract while flow doesn't. > > One drastic approach would be to stop flow from being able to access > java at all, if not thru FOM. I would be in favor of that > once we have > the real block system running, but at that point it might > well be too late. we already have a nice system of flow helper methods to access entity beans and pump them into XML. we use flow to select which components are needed when, and the contract with our GUI designers is XML. we were already burnt quite badly when sendPage() became a requirement, since we were using flow to merely select actions and the sitemap had all of our branching. we are now unable to upgrade past 2.1.2 without major refactoring which honestly we can't afford to do. you theoreticians seem all too willing to break production systems to enforce your latest notion of best practices.
RE: [RT] Use of flowscript or the pyramid of contracts (was Re: [RT] Checked exceptions considered harmful)
Guido Casper <[EMAIL PROTECTED]> writes: > As I alway try to keep my flowscript as "exception-handling-free" as > possible and as I feel that this sentiment is not shared by > everyone, I > thought it is a good oportunity to come up with another concern. > > Hope it's OK to steal this thread. > > Antonio Gallardo wrote: > > Hi Ugo: > > > > I understand that "time" is a good teacher. Things that now are > > easy,some years ago was not. Building the first path is the worse > > task. And since programming is a very dynamic beast, where what > > yesterday was the "best and recommended by the gurus", > today "the same > > gurus tell you that this is totally wrong". > > Yes, not only the gurus' opinions changed but "things" changed. > > I keep on wondering wether it just takes time to build best > practices or > best practices are really constantly changing. > > If I could choose between constantly adjusting best practices > or seeking > for a long term strategy I would (obviously) opt for the > latter. I'm not > sure what would be best for Cocoon though (probably doing both). I think there is something else going on here also: as technologies mature there is a push to make them more accessible. Making them more accessible means adding in capabilities that don't require formal CS training. JavaScript and scripting languages in general are a good example of this. They enable a whole new level of accessibility for a whole new audience that wants to "just do it" and have never heard of best practices. This is good, the demand for such a level of capability means a product has reached a level of appeal where even non CS users are wanting to use it. As such, we shouldn't be surprised if some of the uses for these capabilities don't employ what a more traditional Cocoon developer would consider best practices. So, my high level advice would be not to try and control such experimentation too much. Watch and see what comes of it and then start to develop a new level of best practices. Cforms is an example of this; the community in general is still working to figure out what is best practices for cforms: how to bind, how to add action handlers, etc. There's a general picture emerging, but it's not clear (as an outside observer) exactly what parts of cforms embody Cocoon flow best practices yet. I think this will become much clearer over time. So, I think, yes, you can have both strategy and best practices but it's just going to take time for the best practices to emerge and having a strategy on how to guide that will help (if we really understand what the strategy will do). > > > Welcome to my first RT :-) Gee, I have RT all the time, I just never write them down ;-)... > From the arrival of flow I liked it very much. But at the > same time I > felt it weakens the pyramid of contracts to a great extent > (as Gianugo > recently pointed out as well). > > The pyramid of contracts defined several roles, but what made it so > powerful (IMO) was the strong contract between a user and a > developer of > Cocoon. I feel like the distinction between these two not being that > clear anymore. > > It may be not immediately clear what this distinction is and > I thought a > lot about it (and my opinion on this may be debatable). So > here it goes: > > "A user is someone building applications without writing a > single line > of Java code." > > Some people might argue: Hm, if you try to build your application > without writing any Java code you end up in a mess. But the > point of the > above is, if that user needs a component written/extended in > Java he can > go to "his" developer and tell him: Go off and build this > component for > me and come back when you're done. When this developer comes > back with > the ready-built component the user goes on finishing his app. > This is a > strong contract. An important detail that easily slips through is the > fact that it is the user being responsible for the application's > architecture not the developer. > > So one might come up with the most simple definition of a > Cocoon user as > "someone building Cocoon apps without having eclipse installed" (Idea > and JBuilder counts as well - but Emacs doesn't :-). > > With flow this distinction is not that clear anymore. I think the line has always been blurred (does a user modify the sitemap?), it's just that flow makes it even more obvious that there is an overlap. The capabilities implemented for flow add capabilities for general scripting (in addition to flow control) that is going to be used; there's a pent up demand for easier development that Flowscript provides. > The original intention of flow was to be a facility to describe page > flow logic, since the sitemap was not suitable for this. This clearly > belongs to the realm of the user building applications (although now > having to code something). The reasoning was that describing > your page >
Re: [RT] Use of flowscript or the pyramid of contracts (was Re: [RT] Checked exceptions considered harmful)
Stefano Mazzocchi wrote:
I believe that inputmodules/outputmodules do already pose a significant
complexity to the clean separation.
Care to explain and examplify why you believe so?
I would certainly agree about that some of the modules; the meta
modules, the database modules and the output modules are overkill, and
that you don't need them when you have flowscripts, (I didn't need them
before either, but that depends of course on what kind of apps you write
and on your prefered style). So if you want to depreciate these stuff
I'm +1.
I believe OTH that some of the "simpler" input modules, especially the
request module, the request attribute module and the flow attribute
module, makes it possible to have a *cleaner* SOC, than it is possible
without them. Let me give a simple example:
First, the content of the table and the sort order in the view of it is
clearly separate concern areas so I would definately not like to insert
the sort order parameter in the "content" with jxtg or something like that.
Now I could transfer the request parameter implicitly to the xslt
processor by turning on the "use-request-parameters" in the trax
transformer. But by doing that I lose info in the sitemap about what
external parameters the sitemap rule depends on. When I return to old
apps or apps written by other developers I find it easier to understand
them if the dependencies on e.g. request params are explicitely
"declared" in the sitemap. It is also gives you controll over caching.
I think input modules *are*not*
necessary once you have a clearly defined way for flow to pass
parameters to the sitemap.
There is a clearly defined way to pass flow params to the sitemap:
{flow-attribute:foo}.
I don't think that the "necesity" argument is that relevant. What counts
is that we should have mechanisms that makes it easy to write web-apps
in a way that gives a clear SOC.
I fail to see that:
sortOrder.js:
function getSortOrder() {
sendPage("table-view",
{"sortOrder": cocoon.request.attibute.sortOrder}
}
would be an improvement in clearity compared to using input modules,
(now I used the flow attribute module, as I don't know about the new
mechanism for passing flow attributes that you refer to above). Of
course, if you want to insert data in the sitemap that requires more
programming than just accessing an attribute value, it is probably
better to do that in flowscripts than by using complicated
configuratioons for meta modules. But that is IMO an argument for
deprecate some of the more "complicated" modules rather than taking them
away completely.
--- o0o ---
So to sumarize my position: I believe that having read access to
attributes in the request object and flow attributes in the sitemap
impoves the SOC and clearity in sitemap, more complicated use of modules
don't.
--- o0o ---
An alternative to input modules that would fullfill my requirements,
would be to have a mechanism in the flow processor that gives access to
(possibly a subset of) the readable attributes in the flow object model.
If we factored out that from the flow object model, we could have a
common model for what should be readable from cocoon by the user; for
flowscripts, the sitemap and maybe in other places like in the bsf
generator. The access language for this "Cocoon object model" in the
sitemap could be the same as for input modules to keep back compability.
By doing something like that we could remove the possible FS about
modules and remove the need for configuring them.
Is it something like this that you have in mind when you want scrap the
input modules?
I do understand this is radical and i'm open for constructive criticism,
but please come up with examples to show me why you really need
inputmodules.
See above.
And yes, I still believe in the pyramid of contracts, even more than in
the past, but the sitemap is not enough, we need something else, we
can't write script in XML.
I think we have two separate concerns here. The first is if something
would be "natural" to put in the sitemap. The other is the question
about XML and scriptabillity. IMO, if we think that the sitemap should
be extended with something that requires scripting, but we can't do that
because the sitemap is XML and "thou shall never do scripting in XML".
Then we should maybe find a new non-XML syntax for the sitemap. The
sitemap is one of the few document types that I never have felt any urge
to apply XSLT on ;) So I wouldn't have anything against a more readable
syntax.
WDYT?
/Daniel
Re: [RT] Use of flowscript or the pyramid of contracts (was Re:[RT] Checked exceptions considered harmful)
On Sun, Apr 18, 2004 at 06:46:41PM -0600, Antonio Gallardo wrote: > Guido Casper dijo: > >> I think that cocoon.getComponent(role) would be enough if writing those > >> components would be as painless as writing flowscript. No need for more > >> complex stuff. > > > > I don't think developers aren't eager to write reusable components. But > > currently it's just that hard to come up with components really making > > the user's life easier. > > Yep. One of the things that refrained us to write components is the too > much overhead they have: > > 1-Implementations of the lifecycle: Configurable, composable, etc. > 2-The (1) give you even more code to write based on the implementations > you choosed in (1). > > And people just want to write a simple hello wold component. The question > is how much lines I need to write. And when we realize it is more than 20 > lines. We are lost. It is really the better way to do things? > > I think the key is in KISS. The Flow Engine is so popular because of his > own simplicity. And that is cool. > > I realize that components are a diferents than FlowEngine scripts. But I > try to sell the concept of easy components writing is what the users need. > An alert is already out: People is starting to (ab)use of FlowEngine code > because they feel it is easier to write the full logic on FlowEngine > instead of writing a component. I think we need think about this fact. On > the mail list are clear samples of how they are even making workarounds to > make things works in Flow at any cost, even when using a component will be > easier (you have full access to many thins and in flow you have not the > same access). But the perception win in this case. > > Components are existed before Flow, but Flow is more popular than writing > components, the question is why? flowscript + notepad vs. components + eclipse. and the winner concerning development lifecycle time is: flowscript. Flowscript is: a) scripted b) automatically reloaded by cocoon after changes without container restart. > I will add I will prefer to change the default FlowEngine language from > javascript to Groovy. I really believe it will give the user a more > productive language with the best Java integration. It will be really a > good tradeoff. What does groovy have that flowscript lacks? For generators it would be much better than XSP but I do not see a value added when talking about flowscript - just another syntax. a) you do not have a groovy editor (with autocompletion) b) you cannot check your script for typos before running Those are two most irritating things in my experience with JS flowscript lg -- __ | / \ |Leszek Gawron// \\ \_\\ //_/ [EMAIL PROTECTED] _\\()//_ .'/()\'. Phone: +48(501)720812 / // \\ \ \\ // recursive: adj; see recursive | \__/ |
Re: [RT] Use of flowscript or the pyramid of contracts (was Re:[RT] Checked exceptions considered harmful)
Guido Casper dijo: >> I think that cocoon.getComponent(role) would be enough if writing those >> components would be as painless as writing flowscript. No need for more >> complex stuff. > > I don't think developers aren't eager to write reusable components. But > currently it's just that hard to come up with components really making > the user's life easier. Yep. One of the things that refrained us to write components is the too much overhead they have: 1-Implementations of the lifecycle: Configurable, composable, etc. 2-The (1) give you even more code to write based on the implementations you choosed in (1). And people just want to write a simple hello wold component. The question is how much lines I need to write. And when we realize it is more than 20 lines. We are lost. It is really the better way to do things? I think the key is in KISS. The Flow Engine is so popular because of his own simplicity. And that is cool. I realize that components are a diferents than FlowEngine scripts. But I try to sell the concept of easy components writing is what the users need. An alert is already out: People is starting to (ab)use of FlowEngine code because they feel it is easier to write the full logic on FlowEngine instead of writing a component. I think we need think about this fact. On the mail list are clear samples of how they are even making workarounds to make things works in Flow at any cost, even when using a component will be easier (you have full access to many thins and in flow you have not the same access). But the perception win in this case. Components are existed before Flow, but Flow is more popular than writing components, the question is why? > The problem I have with cocoon.getComponent() is the user's side of the > fence. getComponent() doesn't say anything about the granularity of a > component as Avalon allows for (and encourages) components of any > granularity. Avalon has been there before flow and is intended to make > the Java developer's life easier not the flow user's. > > The services for flow users should be coarse grained and high level. And > I believe that the user shouldn't have to deal with technical details > like component lifecycle (and having to call releaseComponent()). > > Please note that I don't want to discuss the pro/vs. release(). I really > don't care wether the developer has to call release (at least right now > :-). > > I for sure don't want to increase overall complexity. But if I could > trade reduced user complexity for increased developer complexity I would > do. a big +1. The reason I'm thinking about this is that I wondered wether the repository block justifies its existence now that we are short before JSR170 comes along. And in my opinion it does. JSR170 is a Java API while I want my _users_ building a CMS. Does it make sense and is it achievable? >> >> >> the JSR 170 is a complex beast. I would wrap it with a Repository avalon >> component, make the interface really simple and pass this to the >> scripting layer, hiding all the complexity inside. > > Exactly. I'm just thinking about a better way than an Avalon component > (and thought it might be the right time to speak up now that we are > designing a new container). > >> >> That's how I would do it. >> >> And yes, I still believe in the pyramid of contracts, even more than in >> the past, but the sitemap is not enough, we need something else, we >> can't write script in XML. > > 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 think we share the same feeling :-D I will add I will prefer to change the default FlowEngine language from javascript to Groovy. I really believe it will give the user a more productive language with the best Java integration. It will be really a good tradeoff. Best Regards, Antonio Gallardo.
Re: [RT] Use of flowscript or the pyramid of contracts (was Re: [RT] Checked exceptions considered harmful)
Stefano Mazzocchi wrote: I don't even have a real proposal. But I'm thinking about restricting flow to FOM and "flow-intended" components (or their "flow-intended" interface like with CForms). Another part may be some guidelines on how to create (which should be simple of course :-) and use such components. Just exposing Avalon or whatever components to flow doesn't seem to be a big (the right) step forward (and part of this "wrong" step seems to be cocoon.getComponent/releaseComponent) as this implicitely tells the user: yes, flowscript and Java components share the same API. Completely disabling the use of arbitrary Java classes from flowscript doesn't seem doable either (it _is_ a useful thing for the developer) or even desirable. What may be a good idea IMO (and please tell me if I'm talking bullshit) is to let "flow-intended" components implement a Scriptable interface (which should always be high level and easy to be used by users) and provide some kind of doclet mechanism that generates the docs for our "official" flowscript API. I think that cocoon.getComponent(role) would be enough if writing those components would be as painless as writing flowscript. No need for more complex stuff. I don't think developers aren't eager to write reusable components. But currently it's just that hard to come up with components really making the user's life easier. The problem I have with cocoon.getComponent() is the user's side of the fence. getComponent() doesn't say anything about the granularity of a component as Avalon allows for (and encourages) components of any granularity. Avalon has been there before flow and is intended to make the Java developer's life easier not the flow user's. The services for flow users should be coarse grained and high level. And I believe that the user shouldn't have to deal with technical details like component lifecycle (and having to call releaseComponent()). Please note that I don't want to discuss the pro/vs. release(). I really don't care wether the developer has to call release (at least right now :-). I for sure don't want to increase overall complexity. But if I could trade reduced user complexity for increased developer complexity I would do. The reason I'm thinking about this is that I wondered wether the repository block justifies its existence now that we are short before JSR170 comes along. And in my opinion it does. JSR170 is a Java API while I want my _users_ building a CMS. Does it make sense and is it achievable? the JSR 170 is a complex beast. I would wrap it with a Repository avalon component, make the interface really simple and pass this to the scripting layer, hiding all the complexity inside. Exactly. I'm just thinking about a better way than an Avalon component (and thought it might be the right time to speak up now that we are designing a new container). That's how I would do it. And yes, I still believe in the pyramid of contracts, even more than in the past, but the sitemap is not enough, we need something else, we can't write script in XML. 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. Guido -- Guido Casper - S&N AG, Competence Center Open Source Tel.: +49-5251-1581-87 Klingenderstr. 5mailto:[EMAIL PROTECTED] D-33100 Paderborn http://www.s-und-n.de -
Re: [RT] Use of flowscript or the pyramid of contracts (was Re: [RT] Checked exceptions considered harmful)
Stefano Mazzocchi wrote: Guido Casper wrote: Why do "flow people" constantly fall back using Java classes? In my case, I tried to avoid it as the plague. Sorry, hit the wrong key and sent the email ;-) Let me continue. Do they put to much into the flow layer? The expectations for the flow layer seem to be so various. I fear that this fact does more harm than good to Cocoon. Hm, I don't even have a definition of "flow layer". Why is there no library of flow components readily available? I don't know but I suspect it's harder to build reusable flow components than it is to build reusable sitemap components (the level of component reusability of the sitemap is unparalleled). At the same time it is too easy to just get my stuff finished with flow. Which is exactly what makes flow currently so powerful and what may count in many cases. However this particular advantage may be just temporary. I think that if we come up with with reusable FOM components, we have failed. on the other hand, I think there are reusable FOM "aspects" that might be reusable, but let's not go there now. sitemap is declarative glue while flow is procedural glue. if there is too much spaghetti code in between them, there is something wrong and we have to fix that. I believe that inputmodules/outputmodules do already pose a significant complexity to the clean separation. I think input modules *are*not* necessary once you have a clearly defined way for flow to pass parameters to the sitemap. You might be right here but don't forget that it is not always web _applications_ why our users take Cocoon. It is very often simple _publishing_. Input modules make it *very* easy for them to e.g. read out a request parameter without having to go the detour of using flowscript. -- Reinhard
Re: [RT] Use of flowscript or the pyramid of contracts (was Re: [RT] Checked exceptions considered harmful)
Stefano Mazzocchi wrote: ... I think input modules *are*not* necessary once you have a clearly defined way for flow to pass parameters to the sitemap. I do understand this is radical and i'm open for constructive criticism, but please come up with examples to show me why you really need inputmodules. Look in Forrest, and especially at the locationmap module that has to be introduced in the next version. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [RT] Use of flowscript or the pyramid of contracts (was Re:[RT] Checked exceptions considered harmful)
Stefano Mazzocchi dijo: > I don't blame flow to be simple, I blame java to be less usable! We have > to fix that to compensate and our problems will be drasticly reduced > because people don't like to write business logic in scripting languages! Good point Stefano. Last week, while discussing about h13y: http://marc.theaimsgroup.com/?t=10815217281&r=1&w=2 Now we are discussing again, what Cocoon is and how the user don't need to compile and don't know Java at all. I saw the same problem again: "While rethinking a requirement because the complexity to develop it under a specific programming language." At that time I refrained my self to post this questions: "Is it problem of h13y requirement or a problem related to our choiced programming language?" "Are we reaching the limits of Java? Is out there another language options?" This questions will raise ranting, because really "touch" a cornerstone Cocoon block base (in this case the programming language) in a sensitive way. But if we want to have more than what Java can provide us, we need to start thinking what is the best for Cocoon too. Can Cocoon live beyond Java? Cocoon life depend on Java? I don't know what to expect in Java 1.5. I just hope we can think about this and expect that the future Java release will make our life easier. On the other way, I believe other projects meet the same Java limits like Cocoon now. How they solved it? Best Regards, Antonio Gallardo
Re: [RT] Use of flowscript or the pyramid of contracts (was Re: [RT] Checked exceptions considered harmful)
Guido Casper wrote: Why do "flow people" constantly fall back using Java classes? In my case, I tried to avoid it as the plague. Sorry, hit the wrong key and sent the email ;-) Let me continue. Do they put to much into the flow layer? The expectations for the flow layer seem to be so various. I fear that this fact does more harm than good to Cocoon. Hm, I don't even have a definition of "flow layer". Why is there no library of flow components readily available? I don't know but I suspect it's harder to build reusable flow components than it is to build reusable sitemap components (the level of component reusability of the sitemap is unparalleled). At the same time it is too easy to just get my stuff finished with flow. Which is exactly what makes flow currently so powerful and what may count in many cases. However this particular advantage may be just temporary. I think that if we come up with with reusable FOM components, we have failed. on the other hand, I think there are reusable FOM "aspects" that might be reusable, but let's not go there now. sitemap is declarative glue while flow is procedural glue. if there is too much spaghetti code in between them, there is something wrong and we have to fix that. I believe that inputmodules/outputmodules do already pose a significant complexity to the clean separation. I think input modules *are*not* necessary once you have a clearly defined way for flow to pass parameters to the sitemap. I do understand this is radical and i'm open for constructive criticism, but please come up with examples to show me why you really need inputmodules. I guess I just want to hear what other people would think about that. Even if this Email leads to nothing but people looking from another perspective, I'm happy :-) I don't even have a real proposal. But I'm thinking about restricting flow to FOM and "flow-intended" components (or their "flow-intended" interface like with CForms). Another part may be some guidelines on how to create (which should be simple of course :-) and use such components. Just exposing Avalon or whatever components to flow doesn't seem to be a big (the right) step forward (and part of this "wrong" step seems to be cocoon.getComponent/releaseComponent) as this implicitely tells the user: yes, flowscript and Java components share the same API. Completely disabling the use of arbitrary Java classes from flowscript doesn't seem doable either (it _is_ a useful thing for the developer) or even desirable. What may be a good idea IMO (and please tell me if I'm talking bullshit) is to let "flow-intended" components implement a Scriptable interface (which should always be high level and easy to be used by users) and provide some kind of doclet mechanism that generates the docs for our "official" flowscript API. I think that cocoon.getComponent(role) would be enough if writing those components would be as painless as writing flowscript. No need for more complex stuff. The reason I'm thinking about this is that I wondered wether the repository block justifies its existence now that we are short before JSR170 comes along. And in my opinion it does. JSR170 is a Java API while I want my _users_ building a CMS. Does it make sense and is it achievable? the JSR 170 is a complex beast. I would wrap it with a Repository avalon component, make the interface really simple and pass this to the scripting layer, hiding all the complexity inside. That's how I would do it. And yes, I still believe in the pyramid of contracts, even more than in the past, but the sitemap is not enough, we need something else, we can't write script in XML. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [RT] Use of flowscript or the pyramid of contracts (was Re: [RT] Checked exceptions considered harmful)
Guido Casper wrote: Welcome to my first RT :-) Lovely! From the arrival of flow I liked it very much. But at the same time I felt it weakens the pyramid of contracts to a great extent (as Gianugo recently pointed out as well). The pyramid of contracts defined several roles, but what made it so powerful (IMO) was the strong contract between a user and a developer of Cocoon. I feel like the distinction between these two not being that clear anymore. This is very valuable criticism. It may be not immediately clear what this distinction is and I thought a lot about it (and my opinion on this may be debatable). So here it goes: "A user is someone building applications without writing a single line of Java code." Ok, let's use this notion for this context. Some people might argue: Hm, if you try to build your application without writing any Java code you end up in a mess. But the point of the above is, if that user needs a component written/extended in Java he can go to "his" developer and tell him: Go off and build this component for me and come back when you're done. When this developer comes back with the ready-built component the user goes on finishing his app. This is a strong contract. An important detail that easily slips through is the fact that it is the user being responsible for the application's architecture not the developer. Yes, this is crucial in the pyramid of contract: Administration tells Logic what to do. So one might come up with the most simple definition of a Cocoon user as "someone building Cocoon apps without having eclipse installed" (Idea and JBuilder counts as well - but Emacs doesn't :-). With flow this distinction is not that clear anymore. Well, I could say that "cocoon is web glue, and a cocoon user is the one that glues the pieces together". Then, I can say that resources are defined in one place and flow logic is defined in another. The original intention of flow was to be a facility to describe page flow logic, since the sitemap was not suitable for this. This clearly belongs to the realm of the user building applications (although now having to code something). Yes, absolutely. The reasoning was that describing your page flow with a piece of (scripting) code is many times clearer than coming up with some obscure FSM-based XML vocabulary. The code would be so simple that any user (having seen some piece of code before) should grasp it immediately. yep. Over time the intention of flow became "glueing your components together". Developers tend to (ab)use flow for "its own benefits" and use it the same way they use Java (Javascript is not all that different from Java). I feel that the goal to build reusable (high level) components went out of focus because of that (it may be harder to build reusable components for the flow layer then it was/is for the sitemap and it may even be harder to hold on to the pyramid of contracts while moving from the publishing to the webapp space). I 100% agree that this is a problem but it's not flow to blame is the fact that java is so much harder to write and avalon components so much harder to install! Let's not throw away the baby with the dirty water here: flow is crucial for the success of our "user" because there is no way that she can be able to control complex webapp flow in the sitemap without resorting to strange things like actions. It is true that flow is so easy to use that programmers abuse it. I've been there myself and I did have to force myself to write components in java instead of writing them in flow directly. But I *did* feel the need for more component orientation, it's just that having to restart the system everytime was just too painful!! With the compiler classloader, things became much easier!!! I don't blame flow to be simple, I blame java to be less usable! We have to fix that to compensate and our problems will be drasticly reduced because people don't like to write business logic in scripting languages! I'm not saying this necessarily is something bad. It just puts a different perspective on the development process. Today with advancement of IDEs and automated build processes these roles and processes may have changed a bit and the user being "responsible" for all the flow layer does not work anyway, does it? Your code repository is the collective entry point into the system (being closely controlled via a set of automated tests) and Cocoon users and developers are working more closely "integrated" (if they are still to be distinguished roles at all). Did the pyramid of contracts silently vanished? I don't think so. Just lift the user to an "educated user" (if he hasn't always been). However this doesn't mean to tell the user: go and figure how to use all the public classes available from the flow layer. It rather means use flow like it's intended to be used and just use a well-defined limited set of available interfaces. At first I thought, don
Re: [RT] Use of flowscript or the pyramid of contracts (was Re: [RT] Checked exceptions considered harmful)
Guido Casper wrote: Some people might argue: Hm, if you try to build your application without writing any Java code you end up in a mess. But the point of the above is, if that user needs a component written/extended in Java he can go to "his" developer and tell him: Go off and build this component for me and come back when you're done. When this developer comes back with the ready-built component the user goes on finishing his app. This is a strong contract. And don't forget the role of XML in the contract: while the user waits for her component to be finished, she can go on and use an XML mockup, changing the implementation only at a later stage. I don't even have a real proposal. But I'm thinking about restricting flow to FOM and "flow-intended" components (or their "flow-intended" interface like with CForms). Another part may be some guidelines on how to create (which should be simple of course :-) and use such components. Just exposing Avalon or whatever components to flow doesn't seem to be a big (the right) step forward (and part of this "wrong" step seems to be cocoon.getComponent/releaseComponent) as this implicitely tells the user: yes, flowscript and Java components share the same API. Well, I think there is room for improvement here, leaving FOM interfaces intact. We have been strongly advocating IoC and passive API, but if we do a reality check, we can see that the way we're using component managers today doesn't quite make a difference between our supposedly passive/inverted API and those arbitrary JNDI lookup from J2EE world: if we keep passing the same component manager around, filled with the same set of components, we are doing nothing different so: Completely disabling the use of arbitrary Java classes from flowscript doesn't seem doable either (it _is_ a useful thing for the developer) or even desirable. What may be a good idea IMO (and please tell me if I'm talking bullshit) is to let "flow-intended" components implement a Scriptable interface (which should always be high level and easy to be used by users) and provide some kind of doclet mechanism that generates the docs for our "official" flowscript API. I tend to like this idea. Or, in a slight variation, a way to expose to flow just a reasonable subset of components via a restricted component manager. I don't think there is a need for a specific interface to be implemented at the component level: a mechanism for the site administrator to label specific components as available to the flow layer (or the opposite: mark some specific components as not available) could be enough. The reason I'm thinking about this is that I wondered wether the repository block justifies its existence now that we are short before JSR170 comes along. And in my opinion it does. JSR170 is a Java API while I want my _users_ building a CMS. Does it make sense and is it achievable? It's difficult to say without having JSR170 available. On pure paper, it makes sense to have a set of glue components, but just as long as contracts are solid. -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Blogging at: http://www.rabellino.it/blog/)
