jon * wrote:
>
> 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.
Why?
<process/>
could be translated into
<xsp:expr>NovellBusiness.process()</xsp:expr>
then the logic can reside in you save java object code. Taglibs are not
evil, man :) It's how you use them.
> >> 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.
If a company has a shitty business practice? C'mon!
> 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.
??? we are talking about two different things.
> > 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.
Ok, got it.
> > 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. :-)
+1 :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
--
----------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
