You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@jakarta.apache.org by Boris Anthony <an...@touchtunes.com> on 1999/08/31 20:09:15 UTC

embed nothing...

Back to some basics:
There are two major "parts" to a web-app: the front-end and the back
end.

Front end is design: graphics, UI, human-computer stuff, marketing, etc
etc...
Back end is DBs, applications, code code and code...

These are two worlds that should have as little to do with each other as
possible. Designers shouldn't meddle in code and coders shouldn't meddle
in design. It even comes down to biology: left brain right brain.

So why, pray tell, are we forced to work in an environment where there's
HTML (et all) embedded in Java, and / or Java embedded in HTML? It is
ridiculous. Designers could (and should!) care less about platforms and
classes and paths and recompilations and server deamons... And the Back
End Boys would be overjoyed to never have to recompile and restart for a
designer 'cause of a missing comma or gif...

I've worked on many projects where I was the middleman between the front
enders and the back enders... and if it weren't for me some of these
projects would've either been command line interfaces (cause that's the
way the engineers think it should be...) or a series of pretty visuals
(a separate screen for every instance? hell!)

Keep the CODE out of the MARKUP, and vice versa. For god's sake develop
a template system that covers the gamut (includes, substitution,
etc...), instead of damning us all to headaches again.


Boris.
- "The left and the right hate no one more than the middle"

Re: embed nothing...

Posted by Eduardo Pelegri-Llopart <pe...@eng.sun.com>.
>  we forced to work in an environment where there's
>   HTML (et all) embedded in Java, and / or Java embedded in HTML?
>
The JSP technology does not "force" you to embed java into HTML.  This
misconception may be because the spec is not clear enough (that would be
mostly my fault), because we do not have good enough additional
documentation (give us some more time), or because people are only looking
at the JSP 1.0 spec and ignoring the JSP 1.1 spec.

JSP is the umbrella term for the Java technology for the generation of
dynamic content.  JSP is based on the Servlet technology and adds mechanims
to take advantage of fixed template data, for scripting, and for high
quality authoring support.

There are several key elements of the technology.  You can add embed HTML
(or XML - JSP 1.0 and JSP 1.1 are agnostic about the content they
manipulate) with scripting and with server-side tags that can be used to
manipulate server-side objects, some of which are implicit and are created
automatically.  There are a few standard tags (in JSP 1.0 & 1.1) and a
mechanism for defining new custom tags.  We are considering a larger set of
standard tags, built using the tag mechanism, for a later release.

Nobody forces the use of scripting.  My personal guess is that different
organizations will have different emphasis on use of scripting and
definition of custom tags.  Maybe even different projects within the same
organization.  In some cases a quick-and-dirty project will use scripting
initially and later move into tags.  Tags are certainly much more reusable
and lead to a better separation of tasks.  We are spending a significant
amount of effort to make Tags easy to write; we will spend more effort later
to make them easy to manipulate with an authoring tool.  We want to enable
the situation where a developer team within a organization will create a tag
library (maybe import some others) that will provide the desired abstraction
that will be used, via a (best-of-breed) authoring tool, by the designers
that will create the presentation of the information to the end-user.

Scripting, per se, is not evil.  You can see it as a 'glue" that helps you
connect together big pieces of functionality that are delivered via tags
that abstract into EJBs, Server-side Beans, other JSP/Servlets, etc.  In
some cases this glue may be generated automatically by the authoring engine,
although that makes it hard to do round-trip authoring.  I see scripting as
an additional mechanism that a development team can choose whether to use or
not.

There is a blurb on the use of beans, scripts, and tags in the JSP 1.1 first
public release.  It needs work but some people may find it useful.

Hope this helps!

    - eduard/o

Boris Anthony wrote:

> Back to some basics:
> There are two major "parts" to a web-app: the front-end and the back
> end.
>
> Front end is design: graphics, UI, human-computer stuff, marketing, etc
> etc...
> Back end is DBs, applications, code code and code...
>
> These are two worlds that should have as little to do with each other as
> possible. Designers shouldn't meddle in code and coders shouldn't meddle
> in design. It even comes down to biology: left brain right brain.
>
> So why, pray tell, are we forced to work in an environment where there's
> HTML (et all) embedded in Java, and / or Java embedded in HTML? It is
> ridiculous. Designers could (and should!) care less about platforms and
> classes and paths and recompilations and server deamons... And the Back
> End Boys would be overjoyed to never have to recompile and restart for a
> designer 'cause of a missing comma or gif...
>
> I've worked on many projects where I was the middleman between the front
> enders and the back enders... and if it weren't for me some of these
> projects would've either been command line interfaces (cause that's the
> way the engineers think it should be...) or a series of pretty visuals
> (a separate screen for every instance? hell!)
>
> Keep the CODE out of the MARKUP, and vice versa. For god's sake develop
> a template system that covers the gamut (includes, substitution,
> etc...), instead of damning us all to headaches again.
>
> Boris.
> - "The left and the right hate no one more than the middle"
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org

Re: embed nothing...

Posted by Serge Knystautas <se...@lokitech.com>.
Cocoon is Java-Apache's (java.apache.org) fledging attempt to separate
designers from developers (by taking XML from somewhere and dynamically
generating HTML using designer-friendly XSL or other templates).  I'd
check that out as it roughly fits your architecture/approach.

Serge Knystautas
Loki Technologies
http://www.lokitech.com

Boris Anthony wrote:
> 
> Hmm, yes, very good point.. forced is probably a too strong word. Also,
> I was just voicing my hope that we can separate the "face" from the
> "brains" ;)
> 
> There's also the whole useabilty factor... compiling and paths and all
> that is second nature to techies, but designers faint at the idea...
> Make a change and save, reload the page and voila! it works... type of
> scenario is what would be optimal...
> 
> Anyhoo, just voicing an opinion, thanks for the chance and the reply! :)
> 
> B.

Re: embed nothing...

Posted by Boris Anthony <an...@touchtunes.com>.
Hmm, yes, very good point.. forced is probably a too strong word. Also,
I was just voicing my hope that we can separate the "face" from the
"brains" ;)

There's also the whole useabilty factor... compiling and paths and all
that is second nature to techies, but designers faint at the idea...
Make a change and save, reload the page and voila! it works... type of
scenario is what would be optimal...

Anyhoo, just voicing an opinion, thanks for the chance and the reply! :)

B.

"Craig R. McClanahan" wrote:
> 
> Boris Anthony wrote:
> 
> > [snip]
> > So why, pray tell, are we forced to work in an environment where there's
> > HTML (et all) embedded in Java, and / or Java embedded in HTML? It is
> > ridiculous.
> 
> I agree with your suggested design approach -- but I'm curious about where
> you see that we are *forced* to combine HTML and Java, in either direction.
> 
> * HTML in Java -- This is *allowed* in Servlets, but you're not required to
> do it.  You can use JSP pages for that (communicating through beans -- see
> the "Redirecting Requests" design model in the JSP spec, and IBM's many
> white papers that encourage this approach).
> 
> * Java in HTML -- The only Java that I embed in my JSP pages is loop
> control for table generation and things like that -- and this is only until
> engines supporting the JSP 1.1 spec are available, when I can embed all
> that kind of thing in custom tag libraries instead.
> 
> JSP certainly *allows* you to combine things and get yourself in trouble,
> but that's not the same thing.  My hardware store can sell me a rope
> without *forcing* me to hang myself with it, even though having the rope
> *allows* me to do so :-).
> 
> Craig McClanahan
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org

Re: embed nothing...

Posted by "Craig R. McClanahan" <cm...@mytownnet.com>.
Boris Anthony wrote:

> [snip]
> So why, pray tell, are we forced to work in an environment where there's
> HTML (et all) embedded in Java, and / or Java embedded in HTML? It is
> ridiculous.

I agree with your suggested design approach -- but I'm curious about where
you see that we are *forced* to combine HTML and Java, in either direction.

* HTML in Java -- This is *allowed* in Servlets, but you're not required to
do it.  You can use JSP pages for that (communicating through beans -- see
the "Redirecting Requests" design model in the JSP spec, and IBM's many
white papers that encourage this approach).

* Java in HTML -- The only Java that I embed in my JSP pages is loop
control for table generation and things like that -- and this is only until
engines supporting the JSP 1.1 spec are available, when I can embed all
that kind of thing in custom tag libraries instead.

JSP certainly *allows* you to combine things and get yourself in trouble,
but that's not the same thing.  My hardware store can sell me a rope
without *forcing* me to hang myself with it, even though having the rope
*allows* me to do so :-).

Craig McClanahan



Re: embed nothing...

Posted by Thor Heinrichs-Wolpert <th...@Echidna.net>.
> But seriously, after having been around the web app block for creeping
> up on 5 years, I can tell you that web application approaches vary

Good to know you guys have almost been doing it as long as we have *g*.  I
agree with the vary widely bit ... our goal in 93 was to deliver the content
of our governmental database (Oracle) over this new thing called a web
browser.  Almost six years later ... still same goals, but vastly different
tools and approaches.  It's good to back to concepts promoted in the 60s ...
like OO.

Thor HW


Re: embed nothing...

Posted by James Duncan Davidson <du...@x180.com>.
Well, it seems that people are having fun on the list.. :)

But seriously, after having been around the web app block for creeping
up on 5 years, I can tell you that web application approaches vary
greatly and that what works well for one team will *bury* another team
alive and vice versa. It's *so* easy to get religious, and so
unproductive 'cause there isn't 1 right solution that works for
everyone.

live and let live to a large degree... 

.duncan

Re: embed nothing...

Posted by Boris Anthony <an...@touchtunes.com>.
Yes, but... Hmmm perhaps an example would be good here...

The project I am working on requires both reading and writing to/from 
a DB (search feature, listings, etc), session tracking and "shopping 
carts". Standard stuff. However, there are mutliple shopping carts 
(number varies) per user...

So, I want to code html "snippets" for <select>s and <table>s which 
get processed by the various servlets.

Aye, i can't get into too much detail, but basically it's becoming a 
nightmare and the only reason the back end guy and I haven't come to 
fist fights is because we get along so well. :) he doesn't want to 
see any HTML and i don't want to see any Java. ...

Basically there are interface elements that need to be dynamically 
generated. I originally wanted to do this mixing PHP3 and Servlets 
but we ran into problems passing along variables...

we see where we get (oh and it has to be finished by next week... yay! :)

B.

>It is my opinion that if there is code specifically orientated to the
>presentation of information then having it in scripting in the HTML.
>
>One just has to be careful that it doesn't extend too far and you end up
>just having all of the code in the JSP/ASP. You should also make every
>effort to encapsulate things in classes or re-usable tags etc...
>
>To implement this effectively you need to have the builders proficient in at
>least basic scripting as it is undesirable to have to have multiple hands
>responsible for a single file. However, if care has been taken to
>encapsulate things properly there shouldn't be much code beyond things like:
>    if (item%2==) put image on left
>    else put image on right.
>
>
>Tom
>
>
>
>Tom Clarke
>Senior Technical Consultant
>AGENCY.COM
>v 212.358.2798
>----- Original Message -----
>From: Stefano Mazzocchi <st...@apache.org>
>To: <ge...@jakarta.apache.org>
>Sent: Tuesday, August 31, 1999 5:46 PM
>Subject: Re: embed nothing...
>
>
>> Boris Anthony wrote:
>> >
>> > Back to some basics:
>> > There are two major "parts" to a web-app: the front-end and the back
>> > end.
>> >
>> > Front end is design: graphics, UI, human-computer stuff, marketing, etc
>> > etc...
>> > Back end is DBs, applications, code code and code...
>> >
>> > These are two worlds that should have as little to do with each other as
>> > possible. Designers shouldn't meddle in code and coders shouldn't meddle
>> > in design. It even comes down to biology: left brain right brain.
>> >
>> > So why, pray tell, are we forced to work in an environment where there's
>> > HTML (et all) embedded in Java, and / or Java embedded in HTML? It is
>> > ridiculous. Designers could (and should!) care less about platforms and
>> > classes and paths and recompilations and server deamons... And the Back
>> > End Boys would be overjoyed to never have to recompile and restart for a
>> > designer 'cause of a missing comma or gif...
>> >
>> > I've worked on many projects where I was the middleman between the front
>> > enders and the back enders... and if it weren't for me some of these
>> > projects would've either been command line interfaces (cause that's the
>> > way the engineers think it should be...) or a series of pretty visuals
>> > (a separate screen for every instance? hell!)
>> >
>> > Keep the CODE out of the MARKUP, and vice versa. For god's sake develop
>> > a template system that covers the gamut (includes, substitution,
>> > etc...), instead of damning us all to headaches again.
>>
>> <no-flame-war-intended-just-an-information>
>>
>> This is exactly the reason I don't like ASP nor JSP because they have
>> the same problem: they mix contexts that should be separated.
>>
>> This is the main reason why I created Cocoon exactly to change this.
>>
>> See http://java.apache.org/cocoon/index.html to know what I mean ;-)
>>
>> </no-flame-war-intended-just-an-information>
>>
>> --
>> Stefano Mazzocchi      One must still have chaos in oneself to be
>>                           able to give birth to a dancing star.
>> <st...@apache.org>                             Friedrich Nietzsche
>> ---------------------------------------------------------------------
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: general-help@jakarta.apache.org
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: general-help@jakarta.apache.org

________________________________________________________________
B_o_r_i_s A_n_t_h_o_n_y
antbo@touchtunes.com

Information Architecure, Web
________________________________________________________________

Re: embed nothing...

Posted by Tom Clarke <tc...@agency.com>.
----- Original Message ----- 
From: Tom Clarke <tc...@agency.com>

> It is my opinion that if there is code specifically orientated to the
> presentation of information then having it in scripting in the HTML.
... is not such a bad thing.



Tom Clarke
Senior Technical Consultant
AGENCY.COM
v 212.358.2798



Re: embed nothing...

Posted by Tom Clarke <tc...@agency.com>.
It is my opinion that if there is code specifically orientated to the
presentation of information then having it in scripting in the HTML.

One just has to be careful that it doesn't extend too far and you end up
just having all of the code in the JSP/ASP. You should also make every
effort to encapsulate things in classes or re-usable tags etc...

To implement this effectively you need to have the builders proficient in at
least basic scripting as it is undesirable to have to have multiple hands
responsible for a single file. However, if care has been taken to
encapsulate things properly there shouldn't be much code beyond things like:
    if (item%2==) put image on left
    else put image on right.


Tom



Tom Clarke
Senior Technical Consultant
AGENCY.COM
v 212.358.2798
----- Original Message -----
From: Stefano Mazzocchi <st...@apache.org>
To: <ge...@jakarta.apache.org>
Sent: Tuesday, August 31, 1999 5:46 PM
Subject: Re: embed nothing...


> Boris Anthony wrote:
> >
> > Back to some basics:
> > There are two major "parts" to a web-app: the front-end and the back
> > end.
> >
> > Front end is design: graphics, UI, human-computer stuff, marketing, etc
> > etc...
> > Back end is DBs, applications, code code and code...
> >
> > These are two worlds that should have as little to do with each other as
> > possible. Designers shouldn't meddle in code and coders shouldn't meddle
> > in design. It even comes down to biology: left brain right brain.
> >
> > So why, pray tell, are we forced to work in an environment where there's
> > HTML (et all) embedded in Java, and / or Java embedded in HTML? It is
> > ridiculous. Designers could (and should!) care less about platforms and
> > classes and paths and recompilations and server deamons... And the Back
> > End Boys would be overjoyed to never have to recompile and restart for a
> > designer 'cause of a missing comma or gif...
> >
> > I've worked on many projects where I was the middleman between the front
> > enders and the back enders... and if it weren't for me some of these
> > projects would've either been command line interfaces (cause that's the
> > way the engineers think it should be...) or a series of pretty visuals
> > (a separate screen for every instance? hell!)
> >
> > Keep the CODE out of the MARKUP, and vice versa. For god's sake develop
> > a template system that covers the gamut (includes, substitution,
> > etc...), instead of damning us all to headaches again.
>
> <no-flame-war-intended-just-an-information>
>
> This is exactly the reason I don't like ASP nor JSP because they have
> the same problem: they mix contexts that should be separated.
>
> This is the main reason why I created Cocoon exactly to change this.
>
> See http://java.apache.org/cocoon/index.html to know what I mean ;-)
>
> </no-flame-war-intended-just-an-information>
>
> --
> Stefano Mazzocchi      One must still have chaos in oneself to be
>                           able to give birth to a dancing star.
> <st...@apache.org>                             Friedrich Nietzsche
> ---------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>


Re: embed nothing...

Posted by Stefano Mazzocchi <st...@apache.org>.
Boris Anthony wrote:
> 
> Back to some basics:
> There are two major "parts" to a web-app: the front-end and the back
> end.
> 
> Front end is design: graphics, UI, human-computer stuff, marketing, etc
> etc...
> Back end is DBs, applications, code code and code...
> 
> These are two worlds that should have as little to do with each other as
> possible. Designers shouldn't meddle in code and coders shouldn't meddle
> in design. It even comes down to biology: left brain right brain.
> 
> So why, pray tell, are we forced to work in an environment where there's
> HTML (et all) embedded in Java, and / or Java embedded in HTML? It is
> ridiculous. Designers could (and should!) care less about platforms and
> classes and paths and recompilations and server deamons... And the Back
> End Boys would be overjoyed to never have to recompile and restart for a
> designer 'cause of a missing comma or gif...
> 
> I've worked on many projects where I was the middleman between the front
> enders and the back enders... and if it weren't for me some of these
> projects would've either been command line interfaces (cause that's the
> way the engineers think it should be...) or a series of pretty visuals
> (a separate screen for every instance? hell!)
> 
> Keep the CODE out of the MARKUP, and vice versa. For god's sake develop
> a template system that covers the gamut (includes, substitution,
> etc...), instead of damning us all to headaches again.

<no-flame-war-intended-just-an-information>

This is exactly the reason I don't like ASP nor JSP because they have
the same problem: they mix contexts that should be separated.

This is the main reason why I created Cocoon exactly to change this.

See http://java.apache.org/cocoon/index.html to know what I mean ;-)

</no-flame-war-intended-just-an-information>

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
---------------------------------------------------------------------