Webware for Python

(First try didn't go through due to a From-address mismatch.)

I'm evaluating WebWare for possible uses at my company.  However, I'm
distressed by how heavyweight and html-specific WebKit.Page is.  I think
it is bothersome, a little confusing, and not very graceful when it
comes to wanting to write a webapp that extends the toolkit.

My primary gripe is that Page seems to be the only reasonable extension
point for writing things, and many things I need to write may not
actually produce HTML.  If I want to do MVC-like actions where decisions
are made and then forward()'ed away to a PSP, writeHTML() is pure
overhead.  If I want to generate a PNG, CSV or other type of content,
it's confusing to override writeHTML() in my derived class.

I suggest a new class, maybe named HTTPAction, be put between
HTTPServlet and Page.  It should contain all the much of what is called
early in a Page (like respondToGet, respondToPost, and _respond) as well
as general utility methods (like forward()) but leave defaultAction():
*blank* (or possibly just throwing an exception).

Page should then override defaultAction() to call writeHTML(), which it
provides along with all the HTML-specific helper-methods.

With this, people who want to write a differently templated page (maybe
something simpler like writeHeader(), writeBody(), writeFooter()) can
derive from this class.  Also, people who want to write elements that
produce something other than a page of HTML have a more natural
extension point that includes the handy _action_ functionality and
utility routines I've mentioned.

This can be done easily and without breaking current applications simply
by pushing some methods into a new class.

If this sounds reasonable, I'll write a patch.  Please respond and
comment.

-- 
kylev@...
  Some people have a way with words, while others... erm... thingy.

On Wed, 29 Sep 2004 17:24:53 -0700
Kyle VanderBeek <kylev-webware@...> wrote:

> I'm evaluating WebWare for possible uses at my company.  However, I'm
> distressed by how heavyweight and html-specific WebKit.Page is.  I think
> it is bothersome, a little confusing, and not very graceful when it
> comes to wanting to write a webapp that extends the toolkit.

I hear you, but what you might want to do is write a new class extending HTTPServlet
or extend Page and override _respond: I'm generating pages using webware with
SimpleTal( generating xml) -> xslt -> html by overriding Page _respond method (it was the
easy way ;-) )

--
Delio

PS what webware is missing IMHO is a way to cleanly set the session class to use and a way
to customise the url to servlet mapping policy ( unless I couldn't find them when I looked
at the code)

Hello Mr. VanderBeek-

I've been using WebWare for a month now and I am rather happy with
Webware.  The thing I like best about Webware is it's simplicity which
makes it easy to alter to do what I want.  As you have already seen, when
a module such as Page isn't exactly right, you can easily follow the code
and write your own.  Previous projects I worked on were in Java and I'm
not sure if Webware being easy to understand and change is due to it being
written in Python or because the designers did such a good job.  Probably
a combination of the two.

Regarding your proposed changes, I subclass from Page (PSPPage actually).
I write mostly pages with a lot of content so I use Dreamweaver and I
don't use any of the writeHeader/Footer/Body() etc.  So I like the idea of
a class that is lighter than Page like you suggest.  On the other hand,
adding another layer in the hierarchy before Page makes things _slightly_
more complicated.  What do others think?  How do we handle the balance
between adding more features and avoiding feature bloat?

-winston

> (First try didn't go through due to a From-address mismatch.)
>
> I'm evaluating WebWare for possible uses at my company.  However, I'm
> distressed by how heavyweight and html-specific WebKit.Page is.  I think
> it is bothersome, a little confusing, and not very graceful when it
> comes to wanting to write a webapp that extends the toolkit.
>
> My primary gripe is that Page seems to be the only reasonable extension
> point for writing things, and many things I need to write may not
> actually produce HTML.  If I want to do MVC-like actions where decisions
> are made and then forward()'ed away to a PSP, writeHTML() is pure
> overhead.  If I want to generate a PNG, CSV or other type of content,
> it's confusing to override writeHTML() in my derived class.
>
> I suggest a new class, maybe named HTTPAction, be put between
> HTTPServlet and Page.  It should contain all the much of what is called
> early in a Page (like respondToGet, respondToPost, and _respond) as well
> as general utility methods (like forward()) but leave defaultAction():
> *blank* (or possibly just throwing an exception).
>
> Page should then override defaultAction() to call writeHTML(), which it
> provides along with all the HTML-specific helper-methods.
>
> With this, people who want to write a differently templated page (maybe
> something simpler like writeHeader(), writeBody(), writeFooter()) can
> derive from this class.  Also, people who want to write elements that
> produce something other than a page of HTML have a more natural
> extension point that includes the handy _action_ functionality and
> utility routines I've mentioned.
>
> This can be done easily and without breaking current applications simply
> by pushing some methods into a new class.
>
> If this sounds reasonable, I'll write a patch.  Please respond and
> comment.
>
> --
> kylev@...
>   Some people have a way with words, while others... erm... thingy.
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out
> more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Webware-devel mailing list
> Webware-devel@...
> https://lists.sourceforge.net/lists/listinfo/webware-devel
>

Hello Mr. VanderBeek-

I've been using WebWare for a month now and I am rather happy with
Webware.  The thing I like best about Webware is it's simplicity which
makes it easy to alter to do what I want.  As you have already seen, 
when
a module such as Page isn't exactly right, you can easily follow the 
code
and write your own.  Previous projects I worked on were in Java and I'm
not sure if Webware being easy to understand and change is due to it 
being
written in Python or because the designers did such a good job.  
Probably
a combination of the two.

Regarding your proposed changes, I subclass from Page (PSPPage 
actually).
I write mostly pages with a lot of content so I use Dreamweaver and I
don't use any of the writeHeader/Footer/Body() etc.  So I like the idea 
of
a class that is lighter than Page like you suggest.  On the other hand,
adding another layer in the hierarchy before Page makes things 
_slightly_
more complicated.  What do others think?  How do we handle the balance
between adding more features and avoiding feature bloat?

-winston

> (First try didn't go through due to a From-address mismatch.)
>
> I'm evaluating WebWare for possible uses at my company.  However, I'm
> distressed by how heavyweight and html-specific WebKit.Page is.  I 
> think
> it is bothersome, a little confusing, and not very graceful when it
> comes to wanting to write a webapp that extends the toolkit.
>
> My primary gripe is that Page seems to be the only reasonable extension
> point for writing things, and many things I need to write may not
> actually produce HTML.  If I want to do MVC-like actions where 
> decisions
> are made and then forward()'ed away to a PSP, writeHTML() is pure
> overhead.  If I want to generate a PNG, CSV or other type of content,
> it's confusing to override writeHTML() in my derived class.
>
> I suggest a new class, maybe named HTTPAction, be put between
> HTTPServlet and Page.  It should contain all the much of what is called
> early in a Page (like respondToGet, respondToPost, and _respond) as 
> well
> as general utility methods (like forward()) but leave defaultAction():
> *blank* (or possibly just throwing an exception).
>
> Page should then override defaultAction() to call writeHTML(), which it
> provides along with all the HTML-specific helper-methods.
>
> With this, people who want to write a differently templated page (maybe
> something simpler like writeHeader(), writeBody(), writeFooter()) can
> derive from this class.  Also, people who want to write elements that
> produce something other than a page of HTML have a more natural
> extension point that includes the handy _action_ functionality and
> utility routines I've mentioned.
>
> This can be done easily and without breaking current applications 
> simply
> by pushing some methods into a new class.
>
> If this sounds reasonable, I'll write a patch.  Please respond and
> comment.
>
> --
> kylev@...
>   Some people have a way with words, while others... erm... thingy.
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on 
> ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give 
> us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out
> more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Webware-devel mailing list
> Webware-devel@...
> https://lists.sourceforge.net/lists/listinfo/webware-devel
>

There's no reason why you can't just create your own version of Page.  I
ran into the same situation as you, in that I didn't want to embed HTML
right into the servlets, so I took Page and cut out what I didn't need
and added a couple of things.  I use my version of Page as the
super-class for all of my servlets.


- Aaron Switzer



On Wed, 2004-09-29 at 20:24, Kyle VanderBeek wrote:
> (First try didn't go through due to a From-address mismatch.)
> 
> I'm evaluating WebWare for possible uses at my company.  However, I'm
> distressed by how heavyweight and html-specific WebKit.Page is.  I think
> it is bothersome, a little confusing, and not very graceful when it
> comes to wanting to write a webapp that extends the toolkit.
> 
> My primary gripe is that Page seems to be the only reasonable extension
> point for writing things, and many things I need to write may not
> actually produce HTML.  If I want to do MVC-like actions where decisions
> are made and then forward()'ed away to a PSP, writeHTML() is pure
> overhead.  If I want to generate a PNG, CSV or other type of content,
> it's confusing to override writeHTML() in my derived class.
> 
> I suggest a new class, maybe named HTTPAction, be put between
> HTTPServlet and Page.  It should contain all the much of what is called
> early in a Page (like respondToGet, respondToPost, and _respond) as well
> as general utility methods (like forward()) but leave defaultAction():
> *blank* (or possibly just throwing an exception).
> 
> Page should then override defaultAction() to call writeHTML(), which it
> provides along with all the HTML-specific helper-methods.
> 
> With this, people who want to write a differently templated page (maybe
> something simpler like writeHeader(), writeBody(), writeFooter()) can
> derive from this class.  Also, people who want to write elements that
> produce something other than a page of HTML have a more natural
> extension point that includes the handy _action_ functionality and
> utility routines I've mentioned.
> 
> This can be done easily and without breaking current applications simply
> by pushing some methods into a new class.
> 
> If this sounds reasonable, I'll write a patch.  Please respond and
> comment.
-- 
Aaron Switzer
aaron@...
416-350-8376 ext. 235

On Thu, Sep 30, 2004 at 08:55:41AM -0400, Aaron Switzer wrote:
> There's no reason why you can't just create your own version of Page.  I
> ran into the same situation as you, in that I didn't want to embed HTML
> right into the servlets, so I took Page and cut out what I didn't need
> and added a couple of things.  I use my version of Page as the
> super-class for all of my servlets.

This is exactly what I'm trying to say.  Page is the logical extension 
point for creating HTML content, whether extending it in a python class 
or PSP.  However, there is no good place create a class that responds to 
GET/POST information and produces anything *other* than HTML.

I'm just asserting that this is a more logical object design.  It's a 
fairly common task in the course of writing a web application to have to 
provide some sort of non-HTML content.  As it stands, you can either (1) 
"extend" Page and writeHTML() and ignore all kinds of cruft you'll never 
use ("Hooray, my grapher object can validateHTML()!") or (2) extend 
HTTPServlet and lose all the helpful functionality like includeURL(),
forward(), session(), write() and _action_ processing.

The new class I'm proposing provides a logical place where one can start 
from to produce content other than HTML (I sound like a broken record on 
this point).

As for simplicity, I don't think it is a stretch in the slighted to say
in the docs that in most cases you should start by extending Page and
overriding writeBody(), but if your needs are more advanced, dig a
little deeper.

Again, this can be done with zero impact to existing applications that 
do a lot by extending Page.

-- 
kylev@...
  Some people have a way with words, while others... erm... thingy.

On Thu, Sep 30, 2004 at 08:55:41AM -0400, Aaron Switzer wrote:
[snip]
> ...so I took Page and cut out what I didn't need
> and added a couple of things.  I use my version of Page as the
> super-class for all of my servlets.

Forgot to mention: doesn't this sentence scream to you that a 
refactoring and creation of a new parent class should be done?  I read 
this as "Page is too heavyweight so I had to ignore good OO design 
concepts and created a new class with lots of duplicate code."

I think this situation is common, and we need a better extension point.

-- 
kylev@...
  Some people have a way with words, while others... erm... thingy.

Actually I didn't refactor Page because I thought it was too heavy, I
kept at least 90% of it unchanged, and in fact added to it.  I changed
it because I wanted to use XML/XSLT to produce my output.

I do agree that a "lower-level" extension point would be useful and more
inline with OO design.  I guess stripping out the HTML specific stuff
would be a good starting point.

- Aaron Switzer



On Thu, 2004-09-30 at 14:40, Kyle VanderBeek wrote:
> On Thu, Sep 30, 2004 at 08:55:41AM -0400, Aaron Switzer wrote:
> [snip]
> > ...so I took Page and cut out what I didn't need
> > and added a couple of things.  I use my version of Page as the
> > super-class for all of my servlets.
> 
> Forgot to mention: doesn't this sentence scream to you that a 
> refactoring and creation of a new parent class should be done?  I read 
> this as "Page is too heavyweight so I had to ignore good OO design 
> concepts and created a new class with lots of duplicate code."
> 
> I think this situation is common, and we need a better extension point

On Thu, Sep 30, 2004 at 03:15:33PM -0400, Aaron Switzer wrote:
> I do agree that a "lower-level" extension point would be useful and more
> inline with OO design.  I guess stripping out the HTML specific stuff
> would be a good starting point.

I couldn't make CVS diff honor the -N flag for some reason, so here is a 
first cut at a new class HTTPContent, containing the non-HTML parts 
formerly in Page (and a diff to Page.py).

Please comment.

I'd like to remove preAction and postAction from Page as well, or at 
least make them be called in a more consistent fashion.  Right now they 
get called for _action_ style things, but not when defaultAction() is 
invoked.  I suggest removing Page.preAction() and Page.postAction() and 
letting them fall through to the empty versions in HTTPContent, and then 
consistently calling them before and after *all* actions, including 
defaultAction().  Maybe this should be another diff...

-- 
kylev@...
  Some people have a way with words, while others... erm... thingy.

On Sat, 2004-10-02 at 13:47, Kyle VanderBeek wrote:

> I couldn't make CVS diff honor the -N flag for some reason, so here
> is a
> first cut at a new class HTTPContent, containing the non-HTML parts
> formerly in Page (and a diff to Page.py).

> Please comment.

Hi Kyle,

I've applied your patch to my local tree, and am testing it with an app
I'm working on to see if there are any incompatibilities.

What happened to Page.validateHTML()? 

peace,
Jason

--
Jason D. Hildebrand
T: 204 775 1212
E: jason@...

On Thu, Oct 07, 2004 at 08:58:01AM -0500, Jason Hildebrand wrote:
> I've applied your patch to my local tree, and am testing it with an app
> I'm working on to see if there are any incompatibilities.
> 
> What happened to Page.validateHTML()? 

Crap!  Ok, I got overly zealous in my deleting.  That was an
unintentional removal.  I'll submit a revised patch in a little bit.

-- 
kylev@...
  Some people have a way with words, while others... erm... thingy.

On Thu, Oct 07, 2004 at 10:21:54AM -0700, Kyle VanderBeek wrote:
> On Thu, Oct 07, 2004 at 08:58:01AM -0500, Jason Hildebrand wrote:
> > I've applied your patch to my local tree, and am testing it with an app
> > I'm working on to see if there are any incompatibilities.
> > 
> > What happened to Page.validateHTML()? 
> 
> Crap!  Ok, I got overly zealous in my deleting.  That was an
> unintentional removal.  I'll submit a revised patch in a little bit.

Updated Page.py.diff attached.  Re-pull from CVS and apply this instead 
of the last one.  I'll include HTTPContent.py too, just for 
completeness.

-- 
kylev@...
  Some people have a way with words, while others... erm... thingy.