Jason,
IMHO, what the folks at SAJAX were trying to do (with including the
javascript code inside the Sajax.pm module) and calling SAJAX::functions
from inside your perl code is just way to complicated for no noticeable (at
least at first look) reason.
I'm sure for more complicated implementations there may be a need for a
helper function or module to make sure the returned content gets back to the
browser properly.
The meat of the technology is really in the JavaScript, not the language
that you're using on the server side. That's why I created a .js file to
encapsulate the XMLHTTPRequest.
The perl code behind it is actually QUITE simple, and in my opinion it
should stay that way. I think XMLHTTPRequest integrates *seamlessly* into
C::A without any Plugins or additional modules (at least for now).
> 1) HTML::Template
> In the PHP example, they have a <? rs_show_javascript(); ?>. Then the
> backend has to worry about escaping the JavaScript code. HTML::Template
> already has a nice ESCAPE feature: <!-- TMPL_VAR NAME="rs_javascript"
> ESCAPE=JS -->
I bypassed this step completely by created the .js file and including the
following in my template
<script type='text/javascript' src='remotescript.js'></script>
> 2) App. Development
> What would the app look like? How can we make it simple for webdevs?
---
> $self->sajax_methods( {
> 'multiply' => { 'params' => [ qw( x y ) ], 'reset_value' => 'z' },
> 'divide' => { 'params' => [ qw( x y ) ], 'reset_value' => 'z' },
> } );
I by passed these steps by creating one standard javascript function that
all of your html file based XMLHTTPRequests use to call a server-side script
instead of a duplicated block of javascript code for each function that
SAJAX currently creates for each one.
Really just think of it as a form submit that returns very simple out put to
a javascript function already on the page as opposed to returning an entire
HTML page.
One plausible use is this:
I have a screen in my app that allows you to associate a record with a group
from a drop-down.
If you haven't created a group by the time you've gotten to the edit record
screen, you could make an XMLHTTPRequest to your code that created the group
(as long as you give the user a "Create New Group" input box on that page.
Your C::A script would receive the request just like it does any other
request, create the group, and return the new group id directly back to the
edit record page.
Now, that page could use a simple block of javascript code to add the new
group to the drop-down menu so that the user could select the group, save
the record and be done.
---
Steve Comrie
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
