You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Mark Ayad <ma...@javamark.com> on 2002/11/02 13:44:07 UTC

identifying views

Hi All

I would like to identify and track every major view (using a pageID) that a client a.k.a browser could request (composite views are a seperate issue). So my question is where would this fit in the framework ?

Let me back track to give all of you an idea. Before the invention of struts I wrote a framework back in the early days of servlets, which essentially a page-view-factory. I was quite simple you passed the page-view-factory a pageID (in the request) and according to some rules it built a page (sent as the response) No Big deal. What I liked about this setup was the pageID.

For me the pageID is like a primary key in a database. Take for example if we had a homepage with pageID=0001. In a site designers perfect world there might be a specification for page 0001 detailing the guidlines for such a page. Now in the case of the application developer page 0001 might require some javascript to be written, or some tag library to be witten. May be on page 0001 there was a form, so somewhere for page 0001 there would be a definition of that form. Finally from the Marketeers point of view because pages have a unique ID tracking is a doddle. Oh when its time for an redesign of the site thats easy too page 0001 has been replaced by 1001 so there is an audit trail too.

So you see building a large website without pageID is like trying to assemble a car with no part numbers ?

Back to the question in the where's best to identify views ? I have some ideas of my own but wanted to see what other creative alternatives people can think of.

Regards

Mark





Re: identifying views

Posted by Mark Ayad <ma...@javamark.com>.
Cedric, Thanks

I have your book - but haven't got to your chapter on tiles yet. The book is
very well written.

I'll let you know when I reach that point, and if what you say can help me.

All the best

Mark

----- Original Message -----
From: "Cedric Dumoulin" <ce...@apache.org>
To: "Struts Users Mailing List" <st...@jakarta.apache.org>
Sent: Monday, November 04, 2002 10:31 AM
Subject: Re: identifying views


>
>   Hi,
>
>   I think it should be possible to do what you want with Tiles. Your
> pageId will be tiles definition names (logical names).
>
>         Cedric
>
> Mark Ayad wrote:
>
> >Hi All
> >
> >I would like to identify and track every major view (using a pageID) that
a client a.k.a browser could request (composite views are a seperate issue).
So my question is where would this fit in the framework ?
> >
> >Let me back track to give all of you an idea. Before the invention of
struts I wrote a framework back in the early days of servlets, which
essentially a page-view-factory. I was quite simple you passed the
page-view-factory a pageID (in the request) and according to some rules it
built a page (sent as the response) No Big deal. What I liked about this
setup was the pageID.
> >
> >For me the pageID is like a primary key in a database. Take for example
if we had a homepage with pageID=0001. In a site designers perfect world
there might be a specification for page 0001 detailing the guidlines for
such a page. Now in the case of the application developer page 0001 might
require some javascript to be written, or some tag library to be witten. May
be on page 0001 there was a form, so somewhere for page 0001 there would be
a definition of that form. Finally from the Marketeers point of view because
pages have a unique ID tracking is a doddle. Oh when its time for an
redesign of the site thats easy too page 0001 has been replaced by 1001 so
there is an audit trail too.
> >
> >So you see building a large website without pageID is like trying to
assemble a car with no part numbers ?
> >
> >Back to the question in the where's best to identify views ? I have some
ideas of my own but wanted to see what other creative alternatives people
can think of.
> >
> >Regards
> >
> >Mark
> >
> >
> >
> >
> >
> >
> >
>
>
> --
> 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: identifying views

Posted by Cedric Dumoulin <ce...@apache.org>.
  Hi,

  I think it should be possible to do what you want with Tiles. Your 
pageId will be tiles definition names (logical names).

        Cedric

Mark Ayad wrote:

>Hi All
>
>I would like to identify and track every major view (using a pageID) that a client a.k.a browser could request (composite views are a seperate issue). So my question is where would this fit in the framework ?
>
>Let me back track to give all of you an idea. Before the invention of struts I wrote a framework back in the early days of servlets, which essentially a page-view-factory. I was quite simple you passed the page-view-factory a pageID (in the request) and according to some rules it built a page (sent as the response) No Big deal. What I liked about this setup was the pageID.
>
>For me the pageID is like a primary key in a database. Take for example if we had a homepage with pageID=0001. In a site designers perfect world there might be a specification for page 0001 detailing the guidlines for such a page. Now in the case of the application developer page 0001 might require some javascript to be written, or some tag library to be witten. May be on page 0001 there was a form, so somewhere for page 0001 there would be a definition of that form. Finally from the Marketeers point of view because pages have a unique ID tracking is a doddle. Oh when its time for an redesign of the site thats easy too page 0001 has been replaced by 1001 so there is an audit trail too.
>
>So you see building a large website without pageID is like trying to assemble a car with no part numbers ?
>
>Back to the question in the where's best to identify views ? I have some ideas of my own but wanted to see what other creative alternatives people can think of.
>
>Regards
>
>Mark
>
>
>
>
>
>  
>


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