[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
RE: [xsl] object-oriented XSL
Subject: RE: [xsl] object-oriented XSL From: "Hunsberger, Peter" <Peter.Hunsberger@xxxxxxxxxx> Date: Wed, 21 Aug 2002 14:57:17 -0500 |
> the idea is based on the concept of using XML as a programming language, > pretty much like XSL, but instead of a declarative, transform-focused > language it would be procedural, even object-oriented. Sorry, I don't see the need. If you're "bending over backwards" to make XSLT do business logic you're probably not using it correctly. In particular, I find that multiple transformations combined with data aggregation from multiple sources is sufficient for representing all logic (not just business logic) completely. This tends to suggest a particular type of processing environment, chained transformations at a minimum, the configurability of Cocoon pipelines being an example of a more complete, more flexible alternative. With this type of environment you can proceed as follows: 1) define data sources for each discrete type of data: authentication/authorization, groups/roles, business objects, presentation objects, and finally metadata about all these sources. 2) If you need to persist context across multiple requests to data (ie; Web applications) then you also need to build ways of tracking/persisting such contexts. Something like Cocoon provides built in ways for you to do this for Web applications. A thin layer wrapper around various http objects suffices for a other servlet based approaches. For non-web based applications file based or database based persistence are alternatives. In any case, you build ways of setting and getting the data sources from 1) into and out of the various contexts. 3) based on the current context you aggregate the necessary data sources from the other contexts as needed to represent the current state of the world: a user is requesting an application = here's what we know about the requested application and the requesting user; the user is requesting a specific set of data = here's what we know about the user, the application, any relevant data requested to date, and the objects that represent the data requested. 4) based on the contextual data and meta data as aggregated in step 3) run a transformation that builds an object tree representing what the user is supposed to (allowed to) see. This is the application of the business rules. Your business rules are meta data organized as XML that are used to prune and enhance the other XML sources. As part of this transformation, the object tree is populated with the data that populates the resultant objects. (Eg; the user was authorized to view the employee object, in the current context the employee object represents the user, the user is authorized to see the data for his or her self.) 5) transform the object representations into whatever presentation format is required. 6) If running a data entry application, you use a similar approach to bundle validation rules into the object representations and to parse the validation rules against the data returned to the application. Validation rules may be implemented in procedural logic (with XML representing the rule invocation), but again, some form of contextual persistence across the invocation of multiple XSLT templates is sufficient. For example: <employee> <start_date> <isMandatory> <isAfterDate source="birth_date"/> </isMandatory> </start_date> </employee> implies that the contents of the current birth_date is in context for the employee object (which in turn encapsulates a start_date object), but if so, I hope you can see how XSLT can handle this? Thinking in terms of using trees to prune and enhance other trees isn't procedural logic and thus may not seem natural if procedural programming is your background. However, it is an efficient and complete programming methodology; the addition of procedural logic is not necessary. If you want procedural logic, use a procedural language (Java comes to mind!), don't invent a new one. If you want to combine XML and procedural methodologies in a single "language" you may want to look at XSP (implemented again in Cocoon, but I believe also other places?) which combines XML and Java. If your concern is that running XSLT may not efficiently use resources but you still want to use XML then I reiterate that the proper alternative is to use a procedural language that handles XML, not invent a new language. If you're doing this for academic reasons, more power to you :-) (But you may want to study functional programming as a whole instead...) XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] How do I do this?, Mike Brown | Thread | RE: [xsl] object-oriented XSL, martin |
Re: [xsl] object-oriented XSL, Mike Brown | Date | Re: [xsl] How do I do this?, Mike Brown |
Month |