On Fri, 15 Mar 2002, Fisher, James wrote:
> Hmm. By "high level", I take it you mean abstraction. Object oriented
> programming seems to serve this purpose well. Why not just something
> similar to
>
> my $Database = Datatbase->new();
>
> $Database->bootstrap();
> $Database->save-temp-package-from-temp-file();
>
> This also goes for your form submission example
Sure, you could do that. Hell, you could do this in assembler if you want.
My point was that given the constraint of the initial decision to use XSL,
you really need a system that works more naturally in an XML environment.
Let's use another example, where the page actually outputs something
dynamic:
<?xml version = "1.0"?>
<xsp:page
xmlns:xsp="http://www.apache.org/1999/XSP/Core";
xmlns:db="res:perl/VR/Kernel/Database"
xmlns:u="res:perl/VR/Kernel/Util"
language="perl"
>
<response>
<tablename><u:form-param name="name"/></tablename>
<db:list-fields descriptions="1">
<db:table><u:form-param name="name"/></db:table>
</db:list-fields>
</response>
</xsp:page>
This XSP file takes a table name as a parameter and outputs the list of
fields in it, with descriptions. The XSL file may put it in a pretty
table, or speak it to you using VXML, or whatever.
How would you do this with your objects example?
print $tablename;
print $Database->list_fields($fdat{name}, 1);
This isn't enough, yet, because list_fields probably returns an arrayref,
and you need XML output anyway.
So now our code might look like:
print "<tablename>$tablename</tablename>\n";
print toxml($Database->list_fields($fdat{name}, 1));
Except in this case our magic XML converter, toxml(), doesn't know what
the container tag is around the list_fields result, nor does it know the
name to give to items within the list.
print "<tablename>$tablename</tablename>\n";
print toxml($Database->list_fields($fdat{name}, 1), 'fields', 'field');
Now we might reasonably expect to get XML, except it doesn't seem any
simpler than the XSP page, and now descriptions of how to do the Perl->XML
conversion is kept within the page rather than with the function where it
belongs.
If we fix up toxml to read some sort of a function description that
contains metadata describing how to render the result...well, we've just
describe TaglibHelper.
If we decide we want to build a function that sends off a DOM tree in
response to the list_fields call, we've pretty much got an old-style
taglib. Plus we have to implement the function twice: once for XML output
and the other for regular Perl output (because other functions might want
to know the list of fields, and in our case some do).
Seems to me the devil's in the details. Once you get into the details of
it all, non-XSP approaches seem to get pretty complicated too. And of the
people at this company who have used XSP a lot, most of them have said XSP
"feels cleaner", although currently it's rather limiting for forms (which
is why we built vrforms, and why Matt built PerForm).
> Then what is the compelling reason for using it. If CGI/mod_perl/objects
> are satisfactory... I was also trying to think of a type of MVC approach.
> There seems to be many levels of MVC ness these days, so here is an example
> of what I am referring to. Say I have a tag lib similar to the following
> <log_page sub_system_name="messaging" page_id="1234" timestamp="blah blah"
> /> (insert your own parameters). There are 250 xsp pages on my site with
> this call and differing parameters. Ok, say the interface changes. I have
> to go into 250 xsp pages and change the call. Now let me take a non XSP
> approach.
I solve this by not breaking the interface once it's been released. Not
that I would create 250 substantially different function calls...in this
case the page_id is a form param and timestamp is time(), so I would have
one XSP file that calls the function and uses form params as its inputs.
> I create a "controller" for each of the sub_systems in my site.
> In it I have "common services" to each subsystem. The "common services" are
> run and then delegation to the proper component ensues. Now if I have 10
> sub_systems on my site, I only have to change the call in 10 places. I
> guess you could do this with an XSP page?! But, it seems more logical to me
> to use perl code. With XSP I feel I am working around it. With perl I feel
> its working around me.
Honestly, how long have you worked with it? I think everybody has that
reaction to everything that's new to them. Give yourself time to get used
to it, and try different peoples' approaches to see what, if anything,
work right for you.
> > Actually, it's probably faster. XSP-based systems create a DOM tree
> directly, which the LibXSLT transforms directly. If you had Embperl (for
> > example) generating XML, that XML would have to be parsed before it could
> be transformed.
>
> I have not yet looked into the low level details related to caching yet.
> Doesn't AxKit create the DOM tree directly after I pass it XML from say
> Embperl? If it doesn't I'm sure I could add it ;-)
Yes, of course it (theoretically) creates the DOM tree. But with XSP, the
DOM is created directly. There's no "big XML string" middle man that
requires parsing.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
