> >>Did you know that in the body of an XMLSubs, you can do things > >>like <%= $Object->URL %> instead of the __URL__. > > > > Unless I misunderstand your meaning, I don't think that would do what I > > want in this instance since the __TOKENS__ are not being processed until
When I was working out the logic of all of this- I thought I was on to a universal processing method-- and have code that demonstrates the basic principles-- but the one thing that kept me stymied was how to handle two situations-- the first I'm beginning to figure out a solution for, the second I'm still stuck on... A) How to pass post-processing formatting information via the XMLSubs mechanism w/o getting into really overblown & bizarre syntactical situations (I want to keep it as intuitive as possible and like the __TOKEN__ concept as its easy to understand and doesn't take up a lot of room). The gist of my dilemma is, by way of example, how to declare that a number that will be substituted for a token value should have a "%.2f" picture-- or some similar issue. In talking all this out I'm starting to develop a solution that might work actually (so all of this has actually been helpful ;) I'm thinking of creating a token definition tag that would allow inline formatting defintions-- perhaps something like: <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> Then the routine would grab the format pictures in pseudo sprintf format (so that additional formatting pictures could be added-- as in %uc2 == 2 uppercase chars, and apply it as needed when rendering the data... Hmm- I think this might work and I already have the bulk of the code to support it... aha!!! thanks for listening, I've got some coding to do ;) :) :) :) : ) :) 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> 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... ;) [..snip..] > > Now I have a question for you... ever since I first started programming > > ASP projects I have been trying to fathom how to use the "default module" > > that goes along with a project?? > If you have an object that is your Application object, or Model in MVC, > then you can abstract things away from your views which are the ASP > scripts. The controller is Apache::ASP itself, plus whatever you add to > Script_OnStart that might affect how the script gets loaded, if at all! 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... 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. > Though in breaking of the MVC paradigm, I often also do nice little > view shorthands & place them in the app object for the web site like: 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...? > You don't need to init the object with the $Request->Form > data at Script_OnStart however, as you can always > reference it via $main::Request->form from any package. Yeah, that's how I do it now. Whenever I need form data, I just scoop it up on the fly at the beginning of a script. I'm thinking of changing how I do that and getting it in the Script_OnStart method and thus already having it available. A minor thing. > It really starts to help lift reusable code out of > your ASP scripts, into some central object, so you can > reuse it better in other places. Having a central > object can help you from having to define lots of > other globals to do your dirty work. Yes, in this particular application I'm currently working on, I do pretty much-- I've only just gotten to the point where it is enough developed that I can start abstracting large chunks of it-- and I've got a good deal of it shoved into an object framework now-- not completely though, still have a bit more to go. 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? I like talking to you Josh, you have a wealth of information! Thanks for your time and patience. John Whitten [EMAIL PROTECTED] Wizard.Org, Inc. -- -------------------------------------------------------------------------------- Check out http://www.Wizard.Org for great deals on Electronic Parts *NEW* Computer Parts & Accessories - Drives - LCD - Systems - Linux -------------------------------------------------------------------------------- ** Affordable Online Store w/Merchant Card Processing & Paypal ** Write to us: [EMAIL PROTECTED] -- Get your Store Online Today! -------------------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
