On 11/24/01 11:38 AM, "Anthony La Forge" <[EMAIL PROTECTED]> wrote:
> Let me start by thanking those that responded to this post, please allow me to > clarify what I'm attempting to do. > > This is the following scenario: > Effectively I am generating a dynamic web page using templates. There is no > guarantee to the structure of the template only as to what objects may or may > not be present in it. Right, you want to let designers have the freedom to create new templates and put them wherever they want, yes? And you don't know exactly what requirements they will need in a template but you are going to provide them with a fixed set of references, yes? > Also, some of those objects are computationally > expensive to produces and should not be created for requests in which they are > not absolutely necessary. Beyond this some of the logic flows are directly > impacted by what variables are contained within the template. To this end it > is necessary to respond to specific variable tokens differently (a namespace > would come in handy right about now). The pull model won't work for you? If you had a single pull tool and made that your single access point to your application model couldn't you control everything from there. What you are trying to do vis-�-vis gleaning reference tokens sounds extremely complicated. > Indeed, given the amount of different > objects that the system could create it would be illogical to write code and > templates for each scenario, Right, you want to be able to provide a set of references for your users but you want to let them mix and match in an arbitrary fashion. Again I think a pull tool would do the trick. > which would only provide n! different static > scenarios. Beyond being an excessive and hard to maintain approach, this > would not provide a customizable solution for my end users as they will not > have access to the source code to modify the logic when they need a new > template. Right, you could maintain everything in a single place using a pull tool. You could also provide more customization by hooking in something like BSF to allow scripting to your more tech savvy clients. > Perhaps it might be more timely at this point to take the velocity text parser > and create functionality to generate my own namespace, however I was hoping > for a cleaner solution that had clearer long term maintainability and > integration w/ Velocity (e.g. something that I didn't have to re-code after a > new release). I still don't understand the need. You read about the pull model and you're sure that doesn't suit your needs. Making another parser to get the references sounds like a nightmare to me. > My only other thought at this point would be to create custom tags for JSP to > generate this code, however I would much rather only use a servlet based > approach to accomplish this (particularly given that 99% of the code is slated > to be servlet based at this point). > > Again, any insight into this issue would be appreciated. I really don't understand why you need the references. How about a use case, that would really help to understand. I honestly still don't. > Regards, > > AGL > -- jvz. Jason van Zyl http://tambora.zenplex.org http://jakarta.apache.org/turbine http://jakarta.apache.org/velocity http://jakarta.apache.org/alexandria http://jakarta.apache.org/commons -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
