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


Hi Beth,

Beth McCanlies <beth@xxxxxxxxxx> writes:
> The server-side include requirements that I'm seeing is being able to
> perform a server-side include from a dynamic po - where the file to be
> included is a relative url.

Great, there certainly seems to be a need for both runtime and compile-time.

> Are there architectural problems in achieving this via a http request - is
> that what you are saying below - that we don't have a url at this point from
> which to derive an absolute location?  And so once we get into the http
> request that we've lost the ability to get an absolute location since we
> don't have an absolute url to work from?

Don't know. Just want to understand the what it means to `include a PO'.  All 
of
the information could be available to generate an HTTP request and include
the response data.  The Apache SSI module support a URL as the specification
of the include, so it makes sense to support this.  

However, there are disavantages to just including raw text.  In particular,
any dynamic URLs in the content will not have JSESSIONID added, keeping
cookieless sessions from working.   A DOM-based mechanism might be a better
option if you are not working with pre-existing SSI pages.

Mark
 
> I could also envision the usefulness of being able to include a po - which 
> also couldn't be
> resolved at compile time.
> 
> - Beth
> 
> markd@xxxxxxxxx wrote:
> 
> > Hi Beth,
> >    Thanks for the input... Some discussion below.
> >
> > Beth McCanlies <beth@xxxxxxxxxx> writes:
> >
> > > - 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.
> >
> > Form validation and support of libraries of javascript are under 
> > consideration
> > as part of Rocks; tieing them together is an interesting idea.  Validation
> > has to be done on both the client and server.  This needs to be done for
> > individual field values and for the form as a whole.
> >
> > > 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.)
> >
> > We are looking into having a table-driven method for generating the form
> > initialization where validation methods could be specified.
> >
> > > So - what's missing here :
> > > - Provide server-side include functionality in the toDocument method
> >
> > Does your application need runtime server-side includes or would it be
> > possible to do them when the page is compiled?
> >
> > Note that the toDocument() method should normally not be used in
> > Enhydra applications.  Instead, use comms.response.writeHTML(Document).
> > This will allow cookieless sessions to work automatically.
> >
> >
> > > 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.
> >
> > The API to presentation objects and servlets is an HTTP request, its not
> > possible to call them from a SSI; one needs a URL to do that.  Some other
> > SSI handler mechanism would be possible.  Can you describe the problem
> > you need to solve with this?
> >
> > Thanks,
> > MArk
> > -----------------------------------------------------------------------------
> > 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
> 
> 
> 
> -----------------------------------------------------------------------------
> 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
-----------------------------------------------------------------------------
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.