This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: object-oriented XSL


> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]