hmm, just a small reaction of one of the 'original' developers of the project Bruno is talking about... maybe it shouldn't have been posted to the mailinglist, but it could be interesting for other developers as well...
(this is the url http://www.scoot.be of the project i will be talking about) 1. (nothing todo with Cocoon) as usual, too many promises were made to the client and thus the time frame in which things had to be done was too small (a little more than 100 days for 2 developers for a yellow pages website build on top of an 'intelligent' searchengine, including DB design, and I happen to know for sure that bruno hasn't dealt with this kind of pressure yet ;-) ) 2. (little todo with Cocoon) someone at the company thought it would be cool to implement the project in C2 (that was around march this year, C2 was still alpha). The latter wouldn't have been a problem if there was someone on the project with some experience in C2, but that was not the case, we had to figure out most of it ourselves, since there was no documentation (although we had some help from tomK who also worked at the same company at the time and new a little more about C2. Why tomK was part of the project you might ask? hey, i wasn't part of managment, i am only a 24 years old developer doing his job ;-) ...). BTW: don't get me wrong, the decision to use C2 was a very good one! 3. (here it comes...) After playing around with C2 for a while in april (which was the fun part), we were ready to make some decisions on how we were going to use C2 and where to put our businesslogic. - No XSP's was the first decision (IMO mixing markup and code is almost always bad, at least one thing i agree with bruno) - The second one was to use transformers to 'transform' descriptive xml that came from a generator to xml that actually contains the data the user wants (the one and only reason i extended the sqltransformer). Each transformer had to do a very small part of the business logic and had to give the resulting xml to the next transformer. The reason is that, when something in the functionality changes, it would be easy to 'plugin' another transformer. And if i am correct, this is the first thing bruno has a problem with: somewhere in the pipeline, the FilterTransformer i wrote is used to get rid of all the superfluous data that can't be shown to the user on the same page. This is layout stuff, but if you do this in XSL, you will pay the price of bad performance!! - The third one was that all layout had to be done with XSLT (ok, that was the easiest one). 4. (so far so good, but...) The further we go, the more difficult the client gets (again, as usual). Although things go very well, he keeps on asking new stuff and wants to change things again and again and again and again... (think you get the picture) Anyway a few days before the end, there were some major new things that had to be done and we didn't have the time the fully anlayze things and implement them as we should. Jan (the other developer) did a very nice job by using XSP and implement them in a record time, so we were able to make the first deadline (about 95% of the site was finished, we couldn't believe it ourselves, and the client even less, because he wouldn't get the fine he was promised when we weren't finished on time). I wouldn't recommend XSP, but XSP isn't as bad as bruno wants you to believe. XSP was designed to be a mix of code and markup, and consequently it can contain business logic. How far you go with this is your decision (but probably more your boss' :-( ). One more thing: we were working with an alpha version (which we regularly updated) of C2 and we had many smaller and bigger problems with it. At the time we couldn't solve every problem we had within C2 and we had to put some flow decisions in XSL. I am the first one to admit that it was/is wrong, but if you can do it in a better way now, don't just talk about it and do it! 5. (almost there...) Although all the business logic was implemented and the site looked nice, it wasn't ready for the public. At that time Jan and I resigned (to start up our own company ;-) ) and tomK took over the project for a while. In that time he did a major job for the C2 community: he tested C2 thoroughly in every why you can imagine (see also the mailings of this summer). The site went live around the same period. TomK also resigned and the project was transfered to other developers... The only thing bruno can blame us is the fact that we were able to make the deadline with a few tradeoffs in the code, but this is the way it goes, and i am sure he will realises this in the (near?) future also ;-) There is only one way to write good code and that is whitout a deadline in sight. Sven On 11 Dec 2001 at 14:39, [EMAIL PROTECTED] wrote: > > > > -----Original Message----- > > From: Tom Klaasen (TeleRelay) [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, December 11, 2001 10:08 AM > > To: [EMAIL PROTECTED] > > Subject: RE: [RT] Managing Flow and Resources > > > > > > > > > > [big fat snip] > > > However, XML allows you to enforce some limitations on the users. Java > > does not. As you can already see in the example above IMHO, > > it gets very > > difficult to cling to and enforce the SOC principle. The > > shopping-cart() > > function seems to be flow control, but the change-address() is already > > business logic IMO. > > > > Of course, the very intelligent programmers who are > > developing this from > > the start, will be able to enforce the SOC for themselves, > > but newcomers > > who learn by trial-and-error (as we all do) will have serious > > difficulties to grasp it, even if they want to. > > Very right indeed. I'm currently working on a cocoon-based project where the > original developers also didn't realize the importance of separating publishing, > flow and business logic. For example, the business logic is partly in the > publishing pipeline, which has as a consequence that certain flow decession can > only be made in an xsl that generates html to redirect to another page (ugly!) > and more such stuff. Also some of the business logic is in xsp's, which is very > annoying because it's not possible to extend one xsp from another, and it's > quite difficult to do unit testing of them. > > Looks to me that a struts-like thing where you replace the jsp part by > cocoon-pipelines would be the way to go (if you want to work xml based). > > > Me too (is this > > English?) had serious difficulties to grasp the SOC in Struts > > eg, and I > > even thought there wasn't one for quite a while. But then again, maybe > > that says more about my capabilities than anything ;-) > > Anyway, Struts is > > also based mainly on java-code, and genericity and SOC is very hard to > > achieve. > > > > On the other hand, XML indeed isn't developed for logic. So maybe we > > should start on an limititions-enforcable programming > > language LEPL ;-) > > > > For business logic, I find java quite a good language, no need for a LEPL > for me :) > > > > What we could do to support user adoption is > > > provide plenty of > > > already implemented functions, and perhaps maybe later a > > > Visio-like GUI to > > > draw the flow. > > > > If you're into Cocoon, you don't like GUI development (except maybe > > Bruno Dumon ;-)). It is a whole different world. So the > > chances are slim > > there will stand up anybody to make a GUI. > > > > GUI development isn't that different from webapp development. It's all based > around MVC (model-view-controller), or in cocoon speek MVC = "business logic" - > "publishing pipeline" - "flow". The fun part in gui development is when you > actually write your own rendering code (the view), instead of reusing existing > widgets. > > -- > Bruno Dumon > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
