You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ecs-dev@jakarta.apache.org by John Crater <jc...@mwsi.net> on 2002/08/13 23:06:36 UTC

html2ecs

Hi,
 
I've been working on an ECS HTML tree builder that reads from a File or
Reader and builds ECS HTML heirarchies. I've actually got something
working (not tested well yet though). I noticed the html2ecs subproject
and that someone had started on this but not completed it. Is there any
interest in something like this out there?
 
John

 

 

RE: html2ecs

Posted by John Crater <jc...@mwsi.net>.
Hi Jon,

Well written. I understand your pull vs. push model. What I have
proposed is a push model no doubt. The push model simply requires the
GUI designer to understand page layout. All of the data access, looping
and conditional logic is still the responsibility of the java programmer
AND his code IS tied to the layout. You are right about that. 

The whole point of your article, unless I missed something, was that the
pull model is superior because it allows the GUI designers to be "free
from the Java engineers" by giving them complete control and
responsibility for the UI. This is true. Except it essentially makes the
GUI person an entry level programmer themselves by requiring them to
understand data models, APIs and (in the case of JSPs), the Java
programming language. If you have a UI person that can do that, you are
lucky and the pull model may be better. If not, the Java programmer will
have to write "dumb down" code so that the UI person can live up to
their new responsibilities. How do you do this except to design beans
that match the page they are to be used on. If you do that, you've
defeated the whole purpose of the pull model and you're back to Java
programmers coding for each web page. 

So, I don't think one way is obviously better than the other. It may
just depend more on the team doing it than anything inherent in the
design paradigm. 

The second problem I have with JSPs and scripting engines like Velocity
is that the end result is a file with THREE different languages all
mixed together (HTML, JavaScript and Java or some other templating
language). That just spells "mess" to me. At least with what I was
proposing you've seperated out the client side display description and
control code from the server side data generation. Maybe I'm just being
anal on this point. :)

So, the whole point of this is that I think ECS could have a role in
this push model beyond what it has now, or used to have. It already has
the data model for HTML. If that model could be created from an HTML
file and the API tweaked to work with that (such as find() methods), I
think it would be exceedingly easy and productive to use. At least it
would offer a workable alternative for people who don't think crowding
everything into one ugly file is the way to go. JMHO.

John
 


-----Original Message-----
From: Jon Scott Stevens [mailto:jon@latchkey.com] 
Sent: Wednesday, August 14, 2002 4:16 PM
To: ecs-dev
Subject: Re: html2ecs


on 8/14/02 1:39 PM, "John Crater" <jc...@mwsi.net> wrote:

> Someone please tell me why this logic is flawed.
> 
> John

http://jakarta.apache.org/turbine/turbine-2/pullmodel.html

-jon


--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: html2ecs

Posted by Jon Scott Stevens <jo...@latchkey.com>.
on 8/14/02 1:39 PM, "John Crater" <jc...@mwsi.net> wrote:

> Someone please tell me why this logic is flawed.
> 
> John

http://jakarta.apache.org/turbine/turbine-2/pullmodel.html

-jon


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: html2ecs

Posted by John Crater <jc...@mwsi.net>.
I don't use ECS for this because I don't want to build my static HTML in
Java. But, I see little advantage mixing my dynamic coding logic
(Velocity, JSP) in my static HTML either. Six of one, half a dozen of
the other so to speak. I also see little value in creating complex
custom tags or specialized Java Beans to do the work for me. If you
could build your static HTML in a visual editor, load that into an ECS
tree in a servlet at runtime and then operate on that html to produce
the dynamic content using ECS, you could create a clean separation
between static and dynamic code, allow for a clear division of labor AND
avoid creating specialized beans or taglibs. This is exactly the model
Windows programmers have been using for years. No one puts C++ code in
their .rc files and no one creates Windows resources by hand when you
can use the visual editor. This model clearly works. I see little
difference for web content.  

Your servlet code would look something like this...

{
	Html html = new HTML("addcontact.html"); // loads
addcontact.html into the ECS model
	Form form = html.getForm("contactForm"); // now we just use the
contents
	form.getInput("name").setValue(name);
	form.getInput("phone_number").setValue(phoneNumber);

	// done!
}

Since the constructor would build the tree, all you have to do is access
the contents using new or existing ECS methods. This just seems simpler
to me.

Someone please tell me why this logic is flawed. 

John


-----Original Message-----
From: Jon Scott Stevens [mailto:jon@latchkey.com] 
Sent: Wednesday, August 14, 2002 1:44 PM
To: ecs-dev
Subject: Re: html2ecs


on 8/13/02 2:06 PM, "John Crater" <jc...@mwsi.net> wrote:

> Hi,
> 
> I've been working on an ECS HTML tree builder that reads from a File 
> or Reader and builds ECS HTML heirarchies. I've actually got something

> working (not tested well yet though). I noticed the html2ecs 
> subproject and that someone had started on this but not completed it. 
> Is there any interest in something like this out there?
> 
> John

It shocks me that people still use ECS for this...take a look at
Velocity. No more hard coding HTML in Java.

http://jakarta.apache.org/velocity/

-jon


--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: html2ecs

Posted by Jon Scott Stevens <jo...@latchkey.com>.
on 8/13/02 2:06 PM, "John Crater" <jc...@mwsi.net> wrote:

> Hi,
> 
> I've been working on an ECS HTML tree builder that reads from a File or
> Reader and builds ECS HTML heirarchies. I've actually got something
> working (not tested well yet though). I noticed the html2ecs subproject
> and that someone had started on this but not completed it. Is there any
> interest in something like this out there?
> 
> John

It shocks me that people still use ECS for this...take a look at Velocity.
No more hard coding HTML in Java.

http://jakarta.apache.org/velocity/

-jon


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>