4 Jan 2005 20:03
5 Jan 2005 12:59
Re: ServletExtensions?
Hi Ken, The primary servlet extensions, with the main servlet class org.oXML.extras.http.ObjectBox, are in the distributed objectbox.jar file. This is the servlet that is documented on the website, it compiles and runs o:XML programs based on the request URL. However there's an alternative and afaik undocumented servlet in the codebase, in a package called org.oXML.extras.servlet. This is where servlet.oml lives. I can't say for sure whether these extensions work with the latest release, as there are no current unit tests. If you (or anyone else?) are currently using the undocumented alternative servlet extensions, as opposed to the ones described on the website, let me know and I will update them if/as necessary. hth, /m On 4 Jan 2005, at 19:03, Ken McCloskey wrote: > Martin, > > Congratulations on the new release. > > What happened to the servlet.oml extension? It does not seem to be in > the jars anymore, and the servlet.oml in the src directory references > older lib paths.(Continue reading)
5 Jan 2005 18:08
Re: ServletExtensions?
Martin, Thanks for the quick response. I like the convenience of org.oXML.extras.http.ObjectBox since it allows you to declare params that are automatically populated by the servlet request parameters, however org.oXML.extras.servlet.ObjectBox allows me to call methods on the req and res variables. For example I'd like to be able to call req.getPathInfo() , which can not be done in org.oXML.extras.http.ObjectBox. The transparency org.oXML.extras.http.ObjectBox provides between command-line calls and servlets for an oxml program is terrific, but occasionally more flexibility is needed on the servlet side of things. Oxml makes life easy for me, thanks for all your hard work. Ken McCloskey From: Martin Klang <martin@...> To: "Ken McCloskey" <ken_mccloskey@...> CC: o-xml@... Subject: Re: [o:XML] ServletExtensions? Date: Wed, 5 Jan 2005 11:59:09 +0000 MIME-Version: 1.0 (Apple Message framework v619) Received: from fatboy.pingdynasty.com ([213.199.34.33]) by mc3-f24.hotmail.com with Microsoft SMTPSVC(5.0.2195.6824); Wed, 5 Jan 2005 04:02:21 -0800 Received: from [192.168.0.2] (unknown [212.18.228.224])by fatboy.pingdynasty.com (Postfix) with ESMTPid EA25969F08; Wed, 5 Jan 2005 11:52:11 +0000 (GMT)(Continue reading)
5 Jan 2005 20:17
Re: ServletExtensions?
Umm, the 'official' servlet should do both. ie with the following program... <o:program xmlns:servlet="http://www.o-xml.com/servlet/" ...> <o:param name="servlet:req"/> <o:param name="servlet:res"/> <o:param name="servlet:servlet"/> <o:param name="o:session"/> <o:param name="param" select="'default'"/> ...you get the request, response and servlet objects, a Map representing the servlet session plus an HTTP parameter (with default value if not set). You can call methods on the servlet objects as usual, eg <o:set path="$servlet:req.getPathInfo()"/> The session thing is new, the advantage being that it also works from the command line. Hope this makes sense. I'll have to go over the docs sometime soon to make sure they're up to date. On 5 Jan 2005, at 17:08, Ken McCloskey wrote: > Oxml makes life easy for me, thanks for all your hard work. Thank you for using it! /m(Continue reading)
6 Jan 2005 05:04
6 Jan 2005 21:37
Metaprogramable expressions?
Of the many XML
dialects for processing (o:XML, dSVG, XSLT, Ant, WS-BPEL, etc), only
JavaML decomposes an expression into XML elements. This makes JavaML
almost unreadable, and indeed JavaML is a dead language. But I wonder,
have these other XML dialects lost some significant opportunity for further
metaprogramming because they don't have structured
expressions?
_______________________________________________ o-xml mailing list o-xml@... http://lists.pingdynasty.com/mailman/listinfo/o-xml
6 Jan 2005 23:20
Re: Metaprogramable expressions?
Hi Brian! On 6 Jan 2005, at 20:37, Miller, Brian wrote: > Of the many XML dialects for processing (o:XML, dSVG, XSLT, Ant, > WS-BPEL, etc), only JavaML decomposes an expression into XML > elements. There's also Jezix [1] - one of its goals is to not contain any unparsed (composit) values. And there's o:XML's MLML [2], which will form the basis of the next generation of o:XML reflection and meta-programming tools. You could also check out SrcML [3]. I think it's always going to be a trade-off between legibility and structural expressiveness. o:XML, like XSLT, aims to be human editable, which limits its usability as a fully structured code format which would be more suitable for different types of machine processing. Of particular importance are function calls and returns, and variable references, which for meta-programming purposes shouldn't be hidden in unparsed expressions. MLML addresses this by providing a language-neutral, fully structured code format. I hope to publish some XML-based AOSD tools in the near future, time allowing (the ground work is done, just need to adapt it to MLML syntax). regards, /m [1] Jezix http://www.tel.fer.hr/users/mtopol/jezix/ [2] MLML http://www.o-xml.org/projects/mlml.html [3] SrcML http://www.srcml.de/
6 Jan 2005 22:51
Re: Metaprogramable expressions?
On Thu, Jan 06, 2005 at 01:37:43PM -0700, Miller, Brian wrote: > Of the many XML dialects for processing (o:XML, dSVG, XSLT, Ant, > WS-BPEL, etc), only JavaML decomposes an expression into XML elements. > This makes JavaML almost unreadable, and indeed JavaML is a dead > language. I wouldn't quite say dead. As I'm working on SrcML (similar to JavaML) we just recently had a request from a company working with JavaML. Also there are some XML based programming languages out there which also decompose expressions. > But I wonder, have these other XML dialects lost some > significant opportunity for further metaprogramming because they don't > have structured expressions? Obviously not. If you have an expression of the kind 'a = b+c' and store it at an abstract level with something like '<expr>a=b+c</expr>' in the extreme case, then this does not change the amount of information contained in the document. So you can choose just how far into the details you want to decompose the source code and still you neither gain nor lose any additional information, as it's still the same code. So you're not theoretically missing out anything, just that in practice you might either have it easier for not having to parse something into more detail or you might have it harder through added complexity when too much was decomposed for your needs. As for the advantages and disadvantages views - and therefore available XML formats - differ. For example the srcML project is approaching this problem by supporting various levels of details in the parsing, so you can choose to decompose the source just as much as you want to. Of course you then have to take care when handling already parsed XML data, as two files might have been parsed at different detail levels. And you're speaking of 'unreadable' which I personally consider an irrelevant point. As I already pointed out in an earlier mail I believe that source code representation in XML should stay in the background. XML is great for tools to work with the code, but as a programmer I prefer having something more readable than XML and so I don't care about the complexity of the underlying format as long as my editor shows me the code in the way I want it to. This also applies to your argumentation insofar as a document with high decomposition could also be viewed through an editor with a certain threshold level being set. This would essentially mean that everything below that threshold level (say below expression level) will be rendered as plain source code again. (This is something SrcML is capable of doing through its ViewPlatform easily, just in case you are interested in writing such an editor :) With kind regards, -- -- Raiser, Frank Student <at> University of Ulm (www.uni-ulm.de) Then anyone who leaves behind him a written manual, and likewise anyone who receives it, in the belief that such writing will be clear and certain, must be exceedingly simple-minded. (Plato)
9 Jan 2005 18:56
Re: SIDE NOTE: CIL Schema
(cc'd to o:XML list, MLML discussion follows below) On 22 Dec 2004, at 9:59, Alexander Genaud wrote: > Is it too early to try Java -> MLML -> CIL and reverse? It's going to require work. I'm currently playing around with the Antlr parser generator, and its Java grammar in particular - I'm looking at ways of making it generate XML output from its AST. That would take care of Java -> MLML. Unfortunately I don't have much time to play around with stuff... Also, CIL is not really a language per se - if you mean Java -> C# via MLML, then these two are quite different. Eg there are no pointers or references in Java (at the source-code-level, that is). > Again, my interest in this project came simply from using > Javascript on a serious project. > ... (description of serious project) ... sounds like a cool project. > I should be able to WRITE IT IN JAVA and as long as I had not > imported any classes, I should be able to convert it to my javascript > framework. Java -> MLML -> Javascript The middle step would involve some code mangling, eg to change polymorphic function calls to your Javascript framework. That could be done as MLML to MLML transformations. > I've recreated the wheel on too many steps. We all do! Enter MLML. Even if you don't use MLML for language translation, you can use it: - to generate HTML/DocBook/PDF docs - to generate UML models in XMI format - to run language analysers, stats tools etc (the first two are already available) If you have a transformation from MLML back to your source language, you can - generate code from UML models (XMI -> MLML available) - apply stereotypes and code transformations using generic MLML tools - eg insert trace/log calls, Design by Contract assertions, simple AOSD. anyhow, I may be rambling now.. Thanks for your interest! Do get involved! Want to write an MLML -> Javascript transformation?! later, /m
10 Jan 2005 12:39
Re: Re: SIDE NOTE: CIL Schema
On Sun, Jan 09, 2005 at 05:56:51PM +0000, Martin Klang wrote: > It's going to require work. I'm currently playing around with the Antlr > parser generator, and its Java grammar in particular - I'm looking at > ways of making it generate XML output from its AST. That would take > care of Java -> MLML. Unfortunately I don't have much time to play > around with stuff... I'm not sure if you have seen it already, so I'll just keep this posting short: Take a look at the parser-java module of SrcML. The java.g[1] and java.tree.g[2] are the enhanced Antlr java grammar (and tree parser) which produce our SrcML output. The generated parser relies on some classes of the parser-shared module and it currently only works for java 1.3 (I have not yet invested time into 1.4 compliance, but from what I know it should only be the assert keyword which is trivial to add). Also comment handling is a bit on the magical side as it is of course impossible to tell what a commment actually belongs to. Right now the parser assumes a simple 'comment belongs to the next statement' heuristic most of the times. But other than that you should be able to quickly make the neccessary changes from SrcML to MLML. In case you have already looked into that and decided to go into a different solution I'd be pleased to hear your arguments on the decision. Of course the process is also possible using a java.g grammar only, however we found the use of a tree grammar to be very advantageous as you don't run into the problem of when to open which tag. This is rather difficult to decide in those cases were java.g is still in the process of looking ahead to find out what actually happens there in the code. Also the resulting tree grammar turned out to be nice for maintaining due to its simple structure (for a grammar at least ;) [1] http://cvs.sourceforge.net/viewcvs.py/srcml/parser-java/java.g?view=markup [2] http://cvs.sourceforge.net/viewcvs.py/srcml/parser-java/java.tree.g?view=markup With kind regards, -- -- Raiser, Frank Student <at> University of Ulm (www.uni-ulm.de) The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents. (Nathaniel Borenstein)
RSS Feed