ObjectWeb Consortium
Search ObjectWeb Mail Archive: 

Advanced Search - Powered by Google


Mail Archive Home | xmlc List | May 2000 Index

<--  Date Index  --> <--  Thread Index  -->

Re: Rocks: some XMLC ideas


Beth McCanlies wrote:
> 
> Hi -
> 
> I wanted to pass along a couple of ideas in the area of XMLC.  I'm 
> interested in getting feedback on whether others see these are being useful 
> additions.

I don't have a lot of experience with XMLC (a few weeks), but I'm always
glad to offer an oppinion...  

t
> 
> Anyway - here they are:
> 
> - Provide automatic type/format checking of input fields via onChange 
> events and javascript validator functions for client validation, and an 
> XMLC-created method(s) for server validation.  This would provide rapid 
> development of form pages, and give a desktop gui input
> validation behavior to the user - providing user validation feedback at the 
> client level where the feedback is much more immediate.
> 
> This functionality could be driven automatically by denoting the expected 
> format of an input field - perhaps by adding a suffix to the ID value that 
> denotes the expected format, i.e., myField_DATE (This is somewhat hacky and 
> hopefully there is a better way to do this.)
> 
> So - what's missing here :
> 
> - the expected behavior in response to an invalid entry at the client level 
> via javascript; this could be simply a dialog box that reports an error in 
> the expected input field
> 
> - whether one and/or multiple server validator methods are provided for 
> server validation - there could be one per format-designated input field - 
> with the app controlling the resulting behavior - and there could be one 
> per page that simply performs validation of all
> format-designated input fields on the page and returns true/false
> 

What I think is needed here is a complete Framework for processing
forms.  The JavaScript is a nice touch, but it doesn't remove the need
for the server (i.e. trusted) side code to do the same validation.  I'm
growing a primitive such framework because it helps me with my project. 
Here's an outline of it:

Abstract Form class which is a PO.  Derived classes must provide an
array of "Field" objects, and another method (runForm) which handles the
processing.  Field classes come in various forms, but they do
self-validation, self-population, and provide error-types that are
unique their type. Customization is easily added be deriving a new class
from Field.  The Form class also provides standard error processing, and
repopulates the form when an error was encountered so that the user
doesn't have to-reenter all that data again.  It would be feasible to
extend the JavaScript support to the Field class.

As I see it, this is only about 20% (a rough guess) of what a good Form
framework should have, and it's been grown very organically...


> - Provide server-side include functionality in the toDocument method
> 
> Extending the toDocument method to perform server-side includes following 
> the apache include convention - and also allowing these includes to be 
> .po's in addition to static data - would provide server-side include 
> functionality to all dynamic pages.  Allowing included
> files to contain includes would be possible with recursive code, with 
> error-checking for possible cyclic includes.

Server-side includes would be REALLY good, but it occurs to me that that
should be VERY easy to do just using "importNode" (at least a high
level).  Do something like
<SPAN CLASS=ENHYDRA_SSI>FromPageHTML.spanName</SPAN>  could be put in
the "including document" to include a SPAN with ID=spanName from the
page FromPage.html.


> 
> One issue here is being able to derive absolute locations from relative 
> static content.  In using apache virtual hosts , different absolute 
> "document roots" can be used for different virtual hosts.  Then all the 
> other content can be relative static content, resulting in
> content specific to the virtual host and using the same "skeleton" across 
> all hosts.  This is useful in populating virtual host content, but this 
> means that to perform a server-side include of a relative url, the absolute 
> url needs to be derivable.
> 
> Any feedback/comments/thoughts are appreciated.
> 
> - Beth
> 
> -----------------------------------------------------------------------------
> To unsubscribe from this mailing list, send email to majordomo@xxxxxxxxxxx
> with the text "unsubscribe rocks-group" in the body of the email.
> If you have other questions regarding this mailing list, send email to
> the list admin at owner-rocks-group@xxxxxxxxxxxx

-- 
David Corbin            
Mach Turtle Technologies, Inc.
http://www.machturtle.com
dcorbin@xxxxxxxxxxxxxx
-----------------------------------------------------------------------------
To unsubscribe from this mailing list, send email to majordomo@xxxxxxxxxxx
with the text "unsubscribe rocks-group" in the body of the email.
If you have other questions regarding this mailing list, send email to
the list admin at owner-rocks-group@xxxxxxxxxxxx




<--  Date Index  --> <--  Thread Index  -->

Reply via email to:

Powered by MHonArc.

Copyright © 1999-2005, ObjectWeb Consortium | contact | webmaster.