on 4/18/00 5:11 AM, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote:
> Oh, I cannot possibly agree more with you here. This is what I call
> "logic" and logic is _never_ expressed in XSLT in Cocoon.
Ok, so then you use taglibs. Still doesn't help solve the problem very well.
>> Using tags and beans
>> are great, but they only get you so far...especially when you are dealing
>> with real world issues where Novell hasn't even documented half of this
>> business logic and you end up adding it in half way through the project.
>
> That's not a problem we can possibly fix with a framework :) I'm afraid.
Actually, it is. One of the beauties of Turbine is that it has this whole
Visitor (==User) tracking system built in which is a wrapper around the
HttpSession object. There are two places where you can stuff data (the User
object is what is put into the HttpSession for you and is associated to an
individual "User" of the system):
User.addTemp()
User.addPerm()
The temporary storage is for session length data and the permanent storage
is a Hashtable that is byte[] serialized behind the scenes for you into a
blob in the database. This makes it REALLY easy to stuff an object into the
session that you can forget about until you actually need it. Since User is
just an interface, you can implement it how ever you like for your needs
(ie: it doesn't have to just serialized into a blob...it could be an
EJB...). Turbine comes with a default implementation (TurbineUser).
Of course a "guest" or "non-logged-in" user doesn't have this data
serialized.
Thus, this problem is solved quite nicely.
> Just FYI, what you call MVC is now more generally called "separation of
> concerns". Not want to teach you anything, my friend, but MVC is not the
> end of it... the best part is the separation of the concerns in
> different environments and the creation of strong contracts between the
> concern areas.
>
> And I totally agree, "separation of concerns" is the key to success :)
I learn something new every day. ;-) Yesterday it was JavaCC and more
Webmacro. :-)
> For example, let's look at scarab and how this could work there, ok?
> good.
Ok! :-)
> Suppose you have a query page where you insert your query parameters.
> Something like (don't look at the schema, just inventing it as I go...
> there is the XForms language that is being developed at W3C for this,
> btw)
>
> <page>
> <query action="post" url="./query">
> <parameter name="bug number" type="number"/>
> <parameter name="assigned to" type="string"/>
> ...
> </query>
> </page>
>
> that is generated by turbine.. then cocoon wraps around and knows how to
> "convert" this into HTML
Stefano, I agree with you! I'm on your side! This is a great way to do
things. But...
Now get a page designer who only knows about HTML to do this...:-) Right
now, I can say...make me a form in your nice GUI application with the
following fields: blah blah and blah.
Will the designers nice GUI application spit out the above? Maybe in the
future...but not today. Today, it spits out HTML.
> No, you're right, there is always a way, the problem is that I see it
> much simpler this way. Why? because following the separation of
> concerns, turbine applications are just very complex content generators.
> And they should have no notion of style and content type.
I agree! That is why I have now teamed up with WM. Turbine simple builds up
a list of objects, stuffs them into the Context and it is up to the page
designer to stick those objects into meaningful places.
> For example, WML decks are normally restricted to 1.5 Kbytes, if the
> page is bigger, the WAP device might not have enough memory to process
> it. Is turbine going to take care of that?
Sure. It *does* have the ability to put some level of control over the
outputstream. Simply count bytes and throw an error. :-)
> It seems much easier for both of us (hey, it's not a matter of mine is
> bigger than yours :) to go like this
>
> web server -> servlet engine -> cocoon -> turbine
>
> then
>
> web server -> servlet engine -> turbine -> cocoon
>
> and totally nonsense like Kevin proposes in JetSpeed
>
> web server -> servlet engine +-> turbine
> +-> cocoon
:-) Actually, I don't care what the picture is as long as they do their
jobs. :-)
> I'm sure you're right, man. I have no idea of what a complex web
> application is since I never wrote one. Never said the opposite.
>
> But from my point of view, just like a servlet is a servlet no matter
> how big it is, a content generator is a content generator, no matter how
> structured and complex it is.
Ah...I would love to change that POV when you have to go about doing a web
application under time pressures. :-) I had to do that for Novell and I
promised myself that I would make it as easy for myself as possible by
grouping all that re-usable design and code into one package that I could
share with a wide group of people who were trying to solve the same problems
I was. That is now Turbine. :-)
> But this discussion is poinless... I will come up with code, sooner or
> later :)
Actually, the discussion isn't pointless, otherwise everyone would have
thrown us off the list already. :-)
-jon
--
Scarab -
Java Servlet Based - Open Source
Bug/Issue Tracking System
<http://scarab.tigris.org/>
--
----------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
