jon * wrote:
>
> on 4/17/00 3:00 PM, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote:
>
> >> No. It is a pretty website (just like a slideshow and a book is a pretty
> >> presentation). It isn't a web application.
> >
> > Given your statement, you're right. But the line is thin, don't you
> > agree?
>
> Actually I don't. Developing a web application is a lot more complicated
> because you need to essentially code up a huge amount of complicated
> business logic. When I did a shopping cart site for Novell, I had to figure
> out and write into code a huge amount of their undocumented purchasing
> business logic. For example, stupid stuff like:
>
> if contract id # starts with a "N"
> set specialid variable true
> fi
>
> 5 screens later
>
> if specialid == true
> add 10% to the purchase price for products that are
> more than $2000
> fi
>
> That stuff is really complicated to code up into XSLT.
Oh, I cannot possibly agree more with you here. This is what I call
"logic" and logic is _never_ expressed in XSLT in Cocoon.
> 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.
> I'm sure that other people around here have had similar experiences with
> their clients...
I'm sure.
> > But I'm secretly working on something that would change that :) (at
> > least, I hope!)
>
> I keep repeating this...I need it today! I don't care what is around the
> corner any longer because I'm pressed with what needs to be solved today...
I know, I know...
> >> Nor do they care to know. I'm like them...I don't want to have to learn XSLT
> >> just to design a web page. Looking at the spec and some of the example
> >> documentation it is totally overwhelming. I want something that it brain
> >> dead simple.
> >
> > I share your vision. But sometimes you just need more than stupid HTML.
>
> That is why I like WM. It is brain dead simple...there is three parts to the
> "language" and that is it:
>
> if
> else
> foreach
>
> It doesn't get much easier than that and the above certainly isn't
> complicated. The other cool thing about WM is the introspection. One would
> have to design more into the language if it didn't have that, but the fact
> that it does and the fact that it works pretty well is AWESOME. It is so MVC
> it is silly.
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 :)
> >> In a web application doing that is generally impossible to do in the real
> >> world because what you did 5 screens previously matters on the screen that
> >> you are working on now. It makes it really hard to do validation on stuff
> >> like that.
> >
> > True, can get very hard. But just like Java has interfaces, XML has
> > schemas.
>
> That sounds like mumbo jumbo :-)...how does that solve the problem?
XML validation is like Java class-casting. Dynamic loading is great, but
it's not strongly typed... you need run-time evaluation. This is what
makes Java so great and so modular for many of us. XML is like that, but
just like you don't use all Java Objects, but you give more properties
to them extending them, in XML you create a language, a markup and
define a schema to validate it.
For example, let's look at scarab and how this could work there, ok?
good.
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
> > Cocoon is not a transformation engine and there is no way it can
> > possible work "after" Turbine. Rather it should go the other way around:
> >
> > request -> Cocoon -> skeleton pages -> turbine components -> structured
> > page -> transformed page
>
> I don't like the words "no way". :-)
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.
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?
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
> > I'll try to dive deeper.
>
> Thanks...my suggestion to you is to try to develop a complex web application
> so that you can get the experience doing it and I don't feel like I'm trying
> to constantly show you that there is problems that need to be solved in this
> area that are unique...
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.
But this discussion is poinless... I will come up with code, sooner or
later :)
--
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]
