> <my:sub ...>
> <fmt>COST:%.2f,AGE:%3d,STATE:%uc2</fmt>
> This item costs __COST__ and you must be __AGE__ years old to buy it in the
> state of __STATE__
> </my:sub>
>
Assuming that the data is available when the my:sub is starting
to get processed, then you can use more XMLSubs to do your dirty work like:
<% my $data_ref = \%data_hash; %>
<my:sub data=$data_ref>
<my:value name='COST' fmt='%.2f' />
<my:value name='STATE' fmt='%uc2' />
</my:sub>
That is at least how I would try to do it.
If you can end up with your document written entirely in XML,
then you are on your way to having your data written entirely
separately from your style, which is a good goal. This is
the XML/XSLT paradigm, but can be implemented with XHTML,
XMLSubs, XSLT, you pick your favorite.
> B) The second issue is harder though and I still haven't thunk up a good
> solution for it yet... and that is how to handle combined or calculated
> post-processed fields-- ie
>
> <my:sub ...>
> __VAR1__ times __VAR2__ = [product here somehow??]
> </my:sub>
>
Be careful... you are creating your own mini language here.
You could do this instead:
<% my $data_ref = \%$data_hash; %>
<my:sub>
<%= $data_ref->{VAR1} * $data_ref->{VAR2} %>
</my:sub>
I caution against going down the create your own mini language
path because it will end up being a language that only you know.
I would recommend more that if you want to inline a mini language,
that you look into rendering inline a bit of a template toolkit
or HTML::Template into your Apache::ASP, so you might have:
<my:tt data=$data>
Template Toolkit mini language processed here
You could then init the template with $data for parameters
</my:tt>
At least TT or HTML::Template are already widely used, and would
suggest you go down that path for extending your Apache::ASP framework.
> While this may seem to get a little convoluted, there are some good reasons
> why you would want this-- for example, say you have a flag and you need to
> calculate something one way if it is set and another way if it isn't-- but
> you don't know until after (or during) the post-processing takes place. I
> guess perhaps there is a limit to how much one can cram into this XMLSubs
> thing... ;)
There is a limit, but I would like to break it. I believe I can add
a lot of power to XMLSubs, if I allow them to also be called at
compile time as an extension, so that the ASP template being compiled
could be modified instead of the output. The runtime model has more
limits, and the compile time model would only be added as an extension.
I have been mulling these kinds of extensions to XMLSubs for a while,
so do not hold your breath.
>
> Hmm -- what I do now is very close to what you're describing but not taking
> the one last step of pulling the actual application itself into an object
> model. I use the Script_OnStart to instantiate several objects but end up
> passing them around using global vars that I then have to keep up with. If
> I'm understanding you correctly, this is a subtle paradigm shift for me that
> shoves the application out of view and into its own application object class
> which the html files (asp files) within that application domain automagically
> get the benefit of (through instantiation in the Script_OnStart method of the
> global.asa) Which then means that they can access all of the application data
> via the application object, and the various application-level methods again
> via the object (which is not to be confused with the official $Application
> object that is already a part of Apache::ASP). So the details of
> instantiation of the application object are effectively obscured from the
> final html renderer file-- the "view" as it were...
>
Yep.
> Thanks for clearing that up. I understand its purpose now. What I've been
> doing hasn't been "wrong" or even ineffective, I just haven't been taking
> full advantage of the one last level of abstraction that's potentially
> available to me. Hmm-- I think I'm going to enjoy exploring this further.
>
Right. The more you get into this stuff, the more effective you become.
Its pretty neat because you can constantly learn how to do things better.
I do all the time, even with Apache::ASP. :)
>
> So what you're saying is that _technically_ this would not be the place to put
> (say) html rendering routines, but that _some_ html rendering routines are so
> fundamental and basic, they might as well be in here? For example, you might
> have a counter object where, in purity, you would not want to dictate any
> particular rendering, but because it is used primarily (and almost
> exclusively) as an html adjunct component, you might want to include a
> 'renderHtml' (or whatever) method that breaks the paradigm a little...?
>
Right. Technically, I think you need to have view objects doing
view things specific to the rendering platform ( HTML ), separate
from the model/App object. Theoretically the App object should be just
as useful in a Tk GUI view renderer as it is with an HTML renderer.
>
> Okay, one last (mostly off-topic question) and I'll quit pestering you for
> awhile ;) I am always worried about including too many files in the end
> product. I know that Linux does a good job of file caching-- so after the
> first time, how bad is the hit really? Will subsequent requests get served
> out of memory-- so the time is comparable to a subroutine call (probably not
> quite in any case) or is there still some significant overhead I'm not
> considering that would really make me want to keep the number of includes to
> a minimum. I have been back and forth on this (in my own deliberations) many
> times without a satisfactory answer-- what do you think?
>
The linux file cache is really efficient, so include away. The virtues
of component decomposition & reusability far outweigh any performance
penalty your site may suffer. Computers get faster, but people don't,
so code maintainability is of greater importance, especially when
the performance hit is small.
If you really want your site to be fast, then precompile your scripts
in the parent httpd. The real performance hit your are saving yourself
from it having to compile the scripts in every child httpd separately.
Read here for more:
http://www.apache-asp.org/tuning.html#Precompile%20S36827838
Regards,
Josh
________________________________________________________________
Josh Chamas, Founder phone:925-552-0128
Chamas Enterprises Inc. http://www.chamas.com
NodeWorks Link Checking http://www.nodeworks.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
