Webware for Python

Hi,

I've been using Webware for the past 6months and have had no trouble
with many of the issues you describe below. I have gained a lot of
knowledge from the apache Turbine project, and have tried to use Webware
+ Cheetah (containment approach) in the same way as the Turbine +
Velocity  approach. This has worked extremely well.

This is my basic servlet inheritance picture.

Page -> BaseApp -> SecureApp -> GenericApplications (this last one is
the one all programmers will write).

BaseApp overrides the _respond method and will define the basic flow of
all my programs (as an example, the BaseApp can do the following in
_respond:
1. Session Validation
2. Program State Validation
3. Action Processing
4. Display Template

Of course BaseApp will always pass steps 1 and 2.

SecureApp is used to define a servlet which requires a login. This
servlet will just override
The Session Validation.

All my servlets which require a login will extend SecureApp and get all
the login stuff automatically. All other apps can just extend BaseApp

> The current convention of Webware development is making it 
> difficult to distribute or reuse servlets.
> 
> It's expected that many pages will not be reusable -- they'll 
> be tied into their applications, calling all sorts of methods 
> that are specific to that application.  But most useful 
> servlets have to tie into *something*, even if they could be 
> reused.  In the case of users, it's an issue of tying into 
> the (presumably) application-specific definition of a user, 
> authentication, etc.  We need ways to provide 
> application-specific information to potentially generic 
> servlets (like a login page).

I use a config file to specify what login page/template and login logic
to use which is loaded up in SecureApp. This allows me to change the
type of login which is required, without having to rewriting any of my
servlets. All I have to do is write a new Login module which follows my
predefined API. The trick of course is coming up with a generic API.

> There is also the matter of site look.  Again, many of us are 
> handling our site look through inheritance -- overriding 
> writeBodyParts or otherwise putting the site look in the 
> SitePage.  Again, the generic servlet needs some way to 
> access this information.

I don't use the inheritance method here for the look. We have instead
used the Cheetah containment approach which also involves separating the
page layout from the form layout.
The layout is all controlled via a config file (i.e you can configure
the type of layout you want and also change it on the fly (but we don't
do that)) and loaded automatically by the BaseApp.

If you look at how Turbine separates their web page, I have followed
them in this department.

Look under "Module Object Encapsulation" at
http://jakarta.apache.org/turbine/turbine-2.2.0/fsd.html

My rules has been, servlets never ever deal with the layout, look of the
resulting web page. All my servlets do is create forms, processs forms,
call the appropriate business logic (which are kept in separate
modules/classes for reusability)), then set and fill up the relevant
searchlist parameters for the next screen.

> Lastly, there's the matter of specializing the generic 
> servlet, which is really just another way of looking at the 
> other two issues, though in this case there's the presumption 
> that the servlet has a basic understanding of what to do, but 
> you want to change that.

I'm not sure what you mean here ? Do you mean to dynamically change the
flow of the program using some sort of configuration (please not xml) ?

> Inheritance just doesn't work for this kind of reuse.  It's 
> onerous to change the inheritance structure of the generic 
> servlet, because that involves editing the actual servlet 
> code, making it no longer generic. 
> Mixins, in my experience, can be very difficult to work with 
> -- the semantics of who's method gets called where can get 
> very confusing. 
> It's also hard to use more than one mixin at the same time, 
> they just aren't gentle with each other.

A cool idea we have played with is to create components which can be
reused in different servlets. To use them, a programmer will just need
to create an instance of this component. This component will then
automatically/dynamically attach itself to the current servlet i.e
insert it's own actions into the servlets action list, dynamically
create new action methods, add itself to the search list etc. Again, the
trick is to come up with a good api for these components. This way, we
avoid having to create mixins, or use inheritance which I agree with you
does not work very well for this purpose.

Hope I've made some sense.

My only complaint so far is not having an integrated resource loader
(think java) type module. I've had to create a module global which I
load in __init__.py. Is this the correct way of handling stuff like this
?


Many Thanks.

Huy

On Mon, 2003-03-03 at 23:05, Huy Do wrote:
> I've been using Webware for the past 6months and have had no trouble
> with many of the issues you describe below. I have gained a lot of
> knowledge from the apache Turbine project, and have tried to use Webware
> + Cheetah (containment approach) in the same way as the Turbine +
> Velocity  approach. This has worked extremely well.

I should say that I'm also happy with writing Webware applications.  My
concern is more with sharing parts of those applications with others.

> This is my basic servlet inheritance picture.
> 
> Page -> BaseApp -> SecureApp -> GenericApplications (this last one is
> the one all programmers will write).

This is the problem I see -- we're all creating mini-frameworks inside
of Webware.  I have my own, and you have yours -- which is fine until
one of us tries to share something with the other.  My servlets will
expect certain facilities which won't be available in your framework,
and vice versa.

I feel we need to bulk up the framework so that we won't each be
creating our own frameworks, and we'll all be on the same page.  Right
now about the only framework we have for servlets is Page, and it's just
not enough.

> If you look at how Turbine separates their web page, I have followed
> them in this department.
> 
> Look under "Module Object Encapsulation" at
> http://jakarta.apache.org/turbine/turbine-2.2.0/fsd.html

Thanks for the link, I'll read that.  There's several concepts from the
Java world that in some way will probably be very helpful for this.  Tag
libraries are probably also dealing with the same issue.

> > Lastly, there's the matter of specializing the generic 
> > servlet, which is really just another way of looking at the 
> > other two issues, though in this case there's the presumption 
> > that the servlet has a basic understanding of what to do, but 
> > you want to change that.
> 
> I'm not sure what you mean here ? Do you mean to dynamically change the
> flow of the program using some sort of configuration (please not xml) ?

No, I usually don't like "configuration" per se, though the line between
program and configuration can be fuzzy sometimes.

For instance, say you have a reusable login screen (boringly simple, but
easy example).  That servlet could display the login form just fine in a
generic fashion, but you might also want to be able to override the form
display while still using the rest of the page.

> A cool idea we have played with is to create components which can be
> reused in different servlets. To use them, a programmer will just need
> to create an instance of this component. This component will then
> automatically/dynamically attach itself to the current servlet i.e
> insert it's own actions into the servlets action list, dynamically
> create new action methods, add itself to the search list etc. Again, the
> trick is to come up with a good api for these components. This way, we
> avoid having to create mixins, or use inheritance which I agree with you
> does not work very well for this purpose.

Yes, that's the sort of thing I've been thinking about

> My only complaint so far is not having an integrated resource loader
> (think java) type module. I've had to create a module global which I
> load in __init__.py. Is this the correct way of handling stuff like this
> ?

Yes, that's about it.  We should add some helper classes to MiscUtils to
make this easier (and just to make it clear that's what you're supposed
to do), but it would all boil down to the same thing anyway.

  Ian

>
>
>>>Lastly, there's the matter of specializing the generic 
>>>servlet, which is really just another way of looking at the 
>>>other two issues, though in this case there's the presumption 
>>>that the servlet has a basic understanding of what to do, but 
>>>you want to change that.
>>>      
>>>
>>I'm not sure what you mean here ? Do you mean to dynamically change the
>>flow of the program using some sort of configuration (please not xml) ?
>>    
>>
>
>No, I usually don't like "configuration" per se, though the line between
>program and configuration can be fuzzy sometimes.
>
>For instance, say you have a reusable login screen (boringly simple, but
>easy example).  That servlet could display the login form just fine in a
>generic fashion, but you might also want to be able to override the form
>display while still using the rest of the page.
>
I went to a Java Struts talk a awhille ago and started thinking about 
Struts for WEbware.
The remote config file of Strutts is way too complicated, but there is a 
good idea in there, a seperation of code and flow.  In the code we 
should say self.forward(loginpage) and tin the config file have a vline 
- 'loginpage': MyCustomLogin

It is very doable to handle what struts does w/ FunformKit and some 
standard framework structure.

You just need to map each action to a class rather then a function, and 
then provide an external file that maps action names to action classes.

four times the work, five times the files, but more portable.

-Aaron

On Tue, 2003-03-04 at 09:41, Aaron Held wrote:
> I went to a Java Struts talk a awhille ago and started thinking about
> Struts for WEbware.
> The remote config file of Strutts is way too complicated, but there is
> a good idea in there, a seperation of code and flow.  In the code we
> should say self.forward(loginpage) and tin the config file have a
> vline - 'loginpage': MyCustomLogin

Yes, this is what Tomcat described as well.  Another option would be for
some sort of search path, so that you could put your own Login page into
the right location, and it would override the built-in login page. 
Though my concern with that is that you would want to inherit from
Webware's Login, but also from your own classes.

Having a search path like that pretty much underlies Zope's
Acquisition.  Maybe I can appreciate acquisition more now, but I still
also find it very difficult, so I'm not sure where I stand.

> You just need to map each action to a class rather then a function,
> and then provide an external file that maps action names to action
> classes.

Are actions derived from servlets, or are they some other type of
class?  I suppose they wouldn't each be just a function, because then
they wouldn't be entirely orthogonal with the servlets (screens? pages?)

> four times the work, five times the files, but more portable.

Then we'll just be more clever!

  Ian

>
>
>>You just need to map each action to a class rather then a function,
>>and then provide an external file that maps action names to action
>>classes.
>>    
>>
>
>Are actions derived from servlets, or are they some other type of
>class?  I suppose they wouldn't each be just a function, because then
>they wouldn't be entirely orthogonal with the servlets (screens? pages?)
>

Actions are drived from action classes that returns an ActionForward 
mapping that is setup via a call to something like 
mapping.findFormward('login') which would read the xml file.

But first it has to pass a subclass of the ActionForm class that returns 
an error hash if there was an error or nothing if it passses basic (you 
filled in the blank) validation.

-Aaron

Ian Sparks wrote:

>>>
> My customers take less of a security risk this way then if they have 
> to install a full client on thier PC's.
> <<
>  
> Offtopic but what is the thinking behind this statement? Why do you 
> feel browser-based is safer than full client?
>  
> Ah, unless you mean by "full client" that the user has a local 
> database, then I'd see your point.

Any security hole in the browser can and should be dealt with by thier 
IT staff.
Any security hole in my app will never be seen untill it has been exploited.

Actually I was thinking of an app I sent out a few years ago where the 
.dll's clobbered other .dlls and any app crashed when you tried to print. 

On a side note, I recently built an app that took advantage of cross 
frame scripting to modify a page loaded from another server, it worked 
on ie 5.5, but ie 6 'fixed' it. 

-Aaron

>     -----Original Message-----
>     *From:* Aaron Held [mailto:aaron@...]
>     *Sent:* Tuesday, March 04, 2003 12:15 PM
>     *To:* Chad Walstrom
>     *Cc:* Webware discuss
>     *Subject:* Re: [Webware-discuss] Use JavaScript with Caution...
>
>     I agree with the sentiment, but using javascript in the manner
>     that we are discussing has allowed me to mimic much of the
>     functionnality of traditional clients over the web.  For wexample
>     I have a complex search system athat was migrated from MS Access. 
>     It is usable w/o javascript, but much more tedious - mainly
>     becuase the users are 'trained' on the existing system.
>
>     Also for Intranet / Extranet situations it is perfectly accectable
>     to mave a min system requirement.  My current system Requires IE,
>     but everything I am coding will also work with  Netscape/Mozaill, 
>     Opera and Konqurer, but If I go with this XMLHTTP then my next
>     project will only support Netscape / IE. 
>
>     My customers take less of a security risk this way then if they
>     have to install a full client on thier PC's.
>
>     Javascript is not the bane of poor web design, poor web designers
>     are the bane of javascript.
>
>     -Aaron
>
>     Chad Walstrom wrote:
>
>>Aaron Held wrote:
>>  
>>
>>>So instead of processing the return xml file, building javascript 
>>>objects and coding a result you just call the 
>>>    
>>>
>>
>>As nifty as this might seem, JavaScript is IMHO the bane of poor web
>>design.  JavaScript is meant for eye-candy, and should only be used in
>>that manner.  We all know that the behavior of JavaScript is not
>>standardized, and depending on the browser or user preferences,
>>JavaScript will not behave in the same manner and may not even exist.
>>
>>How many sites have you visited in the past and present that are IE-only
>>or Mozilla-only.  Far fewer of the latter than the former, but generally
>>speaking, JavaScript limits the usefulness of any website.
>>
>>With that in mind as a note of caution, please consider maintaining
>>functionality for basic web browsers and those people who do not allow
>>JavaScript to run for security reasons (like myself).  Program to the
>>least-common denominator.
>>
>>Another note of caution: NEVER trust the client.  IOW, ALWAYS validate
>>the client response and be aware of the impact of passing values to
>>method calls.  A common mistake is to use JavaScript to validate forms
>>before submission, and to trust that data as "clean".  JavaScript is a
>>nice convenience for the user, but that is all.  The data you receive
>>at the server could have easily been custom scripted to exploit your
>>application.  Without validation and filtering, your app could be open
>>to all kinds of nasties.
>>
>>Sorry about the preachiness, but JavaScript is one of my largest
>>pet-peeves.  It can be used to create some neat web-effects and
>>conveniences, but it's just not safe to rely upon.
>>
>>  
>>
>

Aaron wrote :
>>
On a side note, I recently built an app that took advantage of cross =
frame scripting to modify a page loaded from another server, it worked =
on ie 5.5, but ie 6 'fixed' it. =20
<<
=20
That's my conceptual problem with web-based applications, you get =
trapped into the "Write once, debug everywhere" cycle because users =
up/downgrade their browsers, mess with their security settings, switch =
cookies on and off. Paradoxically the *promise* of a ubiqitous client =
that you don't have to install and maintain is why I'm lurking in =
Webware-discuss.=20
=20
I can't help feeling that even web state-of-the-art is frustratingly =
stoneage at the moment.

-----Original Message-----
From: Aaron Held [mailto:aaron@...]
Sent: Tuesday, March 04, 2003 1:02 PM
To: Ian Sparks
Cc: Webware discuss
Subject: Re: [Webware-discuss] Use JavaScript with Caution...


Ian Sparks wrote:


>>
My customers take less of a security risk this way then if they have to =
install a full client on thier PC's.
<<
=20
Offtopic but what is the thinking behind this statement? Why do you feel =
browser-based is safer than full client?=20
=20
Ah, unless you mean by "full client" that the user has a local database, =
then I'd see your point.


Any security hole in the browser can and should be dealt with by thier =
IT staff.
Any security hole in my app will never be seen untill it has been =
exploited.

Actually I was thinking of an app I sent out a few years ago where the =
.dll's clobbered other .dlls and any app crashed when you tried to =
print. =20

On a side note, I recently built an app that took advantage of cross =
frame scripting to modify a page loaded from another server, it worked =
on ie 5.5, but ie 6 'fixed' it. =20

-Aaron



-----Original Message-----
From: Aaron Held [ mailto:aaron@...]
Sent: Tuesday, March 04, 2003 12:15 PM
To: Chad Walstrom
Cc: Webware discuss
Subject: Re: [Webware-discuss] Use JavaScript with Caution...


I agree with the sentiment, but using javascript in the manner that we =
are discussing has allowed me to mimic much of the functionnality of =
traditional clients over the web.  For wexample I have a complex search =
system athat was migrated from MS Access.  It is usable w/o javascript, =
but much more tedious - mainly becuase the users are 'trained' on the =
existing system.

Also for Intranet / Extranet situations it is perfectly accectable to =
mave a min system requirement.  My current system Requires IE, but =
everything I am coding will also work with  Netscape/Mozaill,  Opera and =
Konqurer, but If I go with this XMLHTTP then my next project will only =
support Netscape / IE. =20

My customers take less of a security risk this way then if they have to =
install a full client on thier PC's.

Javascript is not the bane of poor web design, poor web designers are =
the bane of javascript.

-Aaron

Chad Walstrom wrote:


Aaron Held wrote:

 =20

So instead of processing the return xml file, building javascript=20

objects and coding a result you just call the=20

   =20



As nifty as this might seem, JavaScript is IMHO the bane of poor web

design.  JavaScript is meant for eye-candy, and should only be used in

that manner.  We all know that the behavior of JavaScript is not

standardized, and depending on the browser or user preferences,

JavaScript will not behave in the same manner and may not even exist.



How many sites have you visited in the past and present that are IE-only

or Mozilla-only.  Far fewer of the latter than the former, but generally

speaking, JavaScript limits the usefulness of any website.



With that in mind as a note of caution, please consider maintaining

functionality for basic web browsers and those people who do not allow

JavaScript to run for security reasons (like myself).  Program to the

least-common denominator.



Another note of caution: NEVER trust the client.  IOW, ALWAYS validate

the client response and be aware of the impact of passing values to

method calls.  A common mistake is to use JavaScript to validate forms

before submission, and to trust that data as "clean".  JavaScript is a

nice convenience for the user, but that is all.  The data you receive

at the server could have easily been custom scripted to exploit your

application.  Without validation and filtering, your app could be open

to all kinds of nasties.



Sorry about the preachiness, but JavaScript is one of my largest

pet-peeves.  It can be used to create some neat web-effects and

conveniences, but it's just not safe to rely upon.



 =20

Ian Sparks wrote:

> I can't help feeling that even web state-of-the-art is frustratingly 
> stoneage at the moment.

This was one of the main factors pushing me towards webware.  I got 
sucked into the java -> framwork - > ide -> gui website builder  and all 
of a sudden my app did not work in xxx browser. And  it took me longer 
to understand the code then it would have if I had written it myself.

One of my eternal pet projects is a community site for sports clubs.  
They are great when I update the site via a web interface, but the 
average  board member always has trouble.  They really need a client 
side app to manage the updates, but I keep trying to improve the web 
interface  with  javascript tricks to make it usable. 

Its a real issue (That you can avoid by embracing microsoft and forcing 
you customers to standardize on IE) The solution to my web interface 
problem is a little dhtml  activeX control. The Mac user will just have 
to buy a new PC.

-Aaron

Nick Murtagh wrote:

> Aaron Held wrote:
>
>> I started looking at XML as a way to handle this, both IE and Moz 6 
>> support calling external xml files, but then you have to parse the 
>> result  and do extra work on the client side.
>
>
> You could also use the XMLHTTP control in IE, there's a similar
> thing in Mozilla. Allows you to make synchronous or asynchronous
> http requests to the server. Write a webware servlet that converts
> simple python objects into a string that can be eval'ed on the
> client so that it turns into a javascript object, and you're
> sorted.
>
> Much less kludgy than the hidden iframe hack, but IE/Moz only.
>
> Nick


I tried this out, but you have to all of the xml processing on the 
client, and I thought it was easier to bypass this entirely.  Now if 
there was an XML-RPC object......

Thanks,
-Aaron


>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of TotalView, The 
> debugger for complex code. Debugging C/C++ programs can leave you 
> feeling lost and disoriented. TotalView can help you find your way. 
> Available on major UNIX and Linux platforms. Try it free. http://www.etnus.com
> _______________________________________________
> Webware-discuss mailing list
> Webware-discuss@...
> https://lists.sourceforge.net/lists/listinfo/webware-discuss

Aaron Held wrote:
> I tried this out, but you have to all of the xml processing on the 
> client, and I thought it was easier to bypass this entirely.  Now if 
> there was an XML-RPC object......

No, read what I wrote! Generate a javascript object in string form
on the server. No nasty XML. Eval the string on the client and, as if
by magic, you have an object.

Nick

Ahh - excellent.
So instead of processing the return xml file, building javascript 
objects and coding a result you just call the 
eval(xmlhttpobject.responseText() );
and have the server send back
<response>
addopt2('aaron','held');
</response>

I like it!

Thanks,
-Aaron

Nick Murtagh wrote:

> Aaron Held wrote:
>
>> I tried this out, but you have to all of the xml processing on the 
>> client, and I thought it was easier to bypass this entirely.  Now if 
>> there was an XML-RPC object......
>
>
> No, read what I wrote! Generate a javascript object in string form
> on the server. No nasty XML. Eval the string on the client and, as if
> by magic, you have an object.
>
> Nick
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of TotalView, The 
> debugger for complex code. Debugging C/C++ programs can leave you 
> feeling lost and disoriented. TotalView can help you find your way. 
> Available on major UNIX and Linux platforms. Try it free. http://www.etnus.com
> _______________________________________________
> Webware-discuss mailing list
> Webware-discuss@...
> https://lists.sourceforge.net/lists/listinfo/webware-discuss

Aaron Held wrote:
> Ahh - excellent.
> So instead of processing the return xml file, building javascript 
> objects and coding a result you just call the 
> eval(xmlhttpobject.responseText() );
> and have the server send back
> <response>
> addopt2('aaron','held');
> </response>
> 
> I like it!

Yeah, it's a pretty useful concept. You can do a simple form of
RPC where strings, ints, tuples, lists, dictionaries get turned
into equivalent javascript objects. Eg

def foo(bar):
   return ['hello', 1, 2]

gets turned into

'_o = new Object(); _o[1] = 'hello'; _o[2] = 1; _o[3] = 2; _o'

This is basically what Microsoft Remote Scripting does, but
without the java proxy. It's trivial to reimplement as a
webware servlet.

Nick

Aaron Held wrote:
> So instead of processing the return xml file, building javascript 
> objects and coding a result you just call the 

As nifty as this might seem, JavaScript is IMHO the bane of poor web
design.  JavaScript is meant for eye-candy, and should only be used in
that manner.  We all know that the behavior of JavaScript is not
standardized, and depending on the browser or user preferences,
JavaScript will not behave in the same manner and may not even exist.

How many sites have you visited in the past and present that are IE-only
or Mozilla-only.  Far fewer of the latter than the former, but generally
speaking, JavaScript limits the usefulness of any website.

With that in mind as a note of caution, please consider maintaining
functionality for basic web browsers and those people who do not allow
JavaScript to run for security reasons (like myself).  Program to the
least-common denominator.

Another note of caution: NEVER trust the client.  IOW, ALWAYS validate
the client response and be aware of the impact of passing values to
method calls.  A common mistake is to use JavaScript to validate forms
before submission, and to trust that data as "clean".  JavaScript is a
nice convenience for the user, but that is all.  The data you receive
at the server could have easily been custom scripted to exploit your
application.  Without validation and filtering, your app could be open
to all kinds of nasties.

Sorry about the preachiness, but JavaScript is one of my largest
pet-peeves.  It can be used to create some neat web-effects and
conveniences, but it's just not safe to rely upon.

-- 
Chad Walstrom <chewie@...>           http://www.wookimus.net/
           assert(expired(knowledge)); /* core dump */

I agree with the sentiment, but using javascript in the manner that we 
are discussing has allowed me to mimic much of the functionnality of 
traditional clients over the web.  For wexample I have a complex search 
system athat was migrated from MS Access.  It is usable w/o javascript, 
but much more tedious - mainly becuase the users are 'trained' on the 
existing system.

Also for Intranet / Extranet situations it is perfectly accectable to 
mave a min system requirement.  My current system Requires IE, but 
everything I am coding will also work with  Netscape/Mozaill,  Opera and 
Konqurer, but If I go with this XMLHTTP then my next project will only 
support Netscape / IE. 

My customers take less of a security risk this way then if they have to 
install a full client on thier PC's.

Javascript is not the bane of poor web design, poor web designers are 
the bane of javascript.

-Aaron

Chad Walstrom wrote:

>Aaron Held wrote:
>  
>
>>So instead of processing the return xml file, building javascript 
>>objects and coding a result you just call the 
>>    
>>
>
>As nifty as this might seem, JavaScript is IMHO the bane of poor web
>design.  JavaScript is meant for eye-candy, and should only be used in
>that manner.  We all know that the behavior of JavaScript is not
>standardized, and depending on the browser or user preferences,
>JavaScript will not behave in the same manner and may not even exist.
>
>How many sites have you visited in the past and present that are IE-only
>or Mozilla-only.  Far fewer of the latter than the former, but generally
>speaking, JavaScript limits the usefulness of any website.
>
>With that in mind as a note of caution, please consider maintaining
>functionality for basic web browsers and those people who do not allow
>JavaScript to run for security reasons (like myself).  Program to the
>least-common denominator.
>
>Another note of caution: NEVER trust the client.  IOW, ALWAYS validate
>the client response and be aware of the impact of passing values to
>method calls.  A common mistake is to use JavaScript to validate forms
>before submission, and to trust that data as "clean".  JavaScript is a
>nice convenience for the user, but that is all.  The data you receive
>at the server could have easily been custom scripted to exploit your
>application.  Without validation and filtering, your app could be open
>to all kinds of nasties.
>
>Sorry about the preachiness, but JavaScript is one of my largest
>pet-peeves.  It can be used to create some neat web-effects and
>conveniences, but it's just not safe to rely upon.
>
>  
>

Chad Walstrom wrote:
> As nifty as this might seem, JavaScript is IMHO the bane of poor web
> design.  JavaScript is meant for eye-candy, and should only be used in
> that manner.  We all know that the behavior of JavaScript is not
> standardized, and depending on the browser or user preferences,
> JavaScript will not behave in the same manner and may not even exist.

Hmm, this is not really web design, it's more application design.
Obviously you would only use this if you know that the intended
users of the system would have the right web browser, or are in
a position to lay down minimum requirements. The technique being
described here cannot be achieved without javascript, and would
only be used in a javascript friendly environment.

Nick

Aaron wrote:
> I agree with the sentiment, but using javascript in the manner that we
> are discussing has allowed me to mimic much of the functionnality of
> traditional clients over the web.

I understand this, and I agree that as designers, we're not always at
liberty to say "Yes" or "No" to a customer's requests.  It wasn't my
objective to question your design, just to throw out a general note of
caution for those using JavaScript for more than Web-UI enhancement.

IMHO, there are ways around the mimicked MVC design requirement, and that
a refactoring of the user interface to a web-centric model can be
sufficient in many cases.  The fewer requirements you place upon the
browser, the fewer problems you have at the browser level.  This is true
whether it is an Intranet or Internet web-application.  The downside is,
of course, retraining the end-user to the new paradigm and making sure
server and network performance is up to snuff.

On a related note, I see this general sentiment of caution applying to
the use of forms and hidden data to drive web applications rather than
session data.  I dread the day that I have to start supporting the
internal Perl project we have at work. *shiver*  If that day happens,
there'll be some major changes to the session handler. (*rip, tear,
replace, grin*) ;-)

Good luck on the project!

-- 
Chad Walstrom <chewie@...>           http://www.wookimus.net/
           assert(expired(knowledge)); /* core dump */

On Mon, 2003-03-03 at 20:41, Tripp Lilley wrote:
> I've been following this thread and it seems to me that all of this
> behaviour built around Page is just -begging- for Mixins or delegates of
> some sort and documentation of an interface for adding behaviour to pages
> through them (e.g., the base Page class will guarantee to call through the
> chain of delegates in a particular order, etc.)

Hmm... at first I thought this was just a slight generalization of what
I was thinking about -- my proposal was really for a set of hooks in
Page, not an actual authentication/security implementation (though the
implementation should be relatively easy to write with the right hooks).

But then I started thinking about other error pages -- which is
something I've been trying work through -- and the problems are
similar.  And there's all sorts of other problems with Webware not being
plugin-friendly on the servlet level.

Anyway, I started another thread about that.  Any concrete ideas about
how this could be improved would be good...

  Ian