Cool. We did find a few ways around some of the limitations in TaglibHelper as well, but your right, in general it is only good for fairly simple cases, more complex taglibs need something like what you're describing (which seems fairly close to the raw XSP interface).
After looking at some other taglibs source code it seems to me that the XSP module itself could probably be enhanced via a few OO perl tricks so that you could just subclass it to create a taglib in a fairly clean way. In essence what it seems like to me is you want to maybe create a set of handlers that do the "compile time" part of the XSP automagically (so you just define methods like "parse_start_mytag($self,...)" and those just get called at the appropriate times. Should be pretty easy with an AUTOLOAD trick or maybe using some tieing tricks. On Wednesday 30 January 2002 17:09, J�rg Walter wrote: > On Wednesday 30 January 2002 21:38, you wrote: > > Here's a thorny problem that relates to his question > > > > I'd like to be able to create something like the following syntax. > > > > <soap:endpoint proxy="bar"> > > <soap:call uri="foo"> > > <soap:method name="AMethodOfFoo"> > > <arg1>gaga</arg1> > > <arg2><param:stuff/></arg2> > > </soap:method> > > </soap:call> > > </soap:endpoint> > > > > Which is all well and good, except it seems not to be possible, at least > > not with TaglibHelper. The reason being that the code generated by the > > <soap:endpoint> call is executed AFTER the code generated by the enclosed > > tags, so the endpoint hasn't been initialized at the time the <soap:call> > > tag's code is invoked:(. > > > > I can see that in the case of the example that Robin shows for > > util:include-file that this is the proper behaviour, and in general you > > would need to do things in that order, but there should be a way to issue > > some code into the XSP module at the point of the OPENING tag. > > > > In fact this is a general case. I could solve it for the simple example > > above by just having the endpoint tag take all the rest of the stuff as > > input args and figure out what to do, but what about that > > <param:stuff/>??? It seems like to me there just isn't a way for > > TaglibHelper based taglibs to implement this kind of syntax, or am I > > missing something here? > > There is an alternative TaglibHelper called SimpleTaglib. It was designed > by me to handle exactly these constructs (and quite a few other less-common > but still generic ones). SimpleTaglib is for now available at > http://www.reg-online.de/SimpleTaglib.pm but will be part of AxKit at some > point. Copy it to the directory where TaglibHelper.pm lives. It is fully > documented, but to help you getting started, here are the two ways you can > solve this problem: (I assume you can spot the placeholders :-) > > package AxKit::XSP::MySoapTaglib; > use Apache::AxKit::Language::XSP::SimpleTaglib; > $AxKit::XSP::MySoapTaglib::NS = 'http://my.host.com/MySoap'; > > package AxKit::XSP::MySoapTaglib::Handlers; > > sub endpoint__open : attrib(proxy) { > my ($e, $tag, %attribs) = @_; > # Initialize and declare stuff. The proxy attribute is: $attribs{'proxy'} > return 'my $endpoint = "initialized to some value";' > } > > sub endpoint { > # Now take some action, if you want. This sub is needed, even if > # it returns nothing (i.e., no action) > return ""; > } > > sub endpoint___call : childStruct($uri $method{$name @arg}) { > # act on a call. all the parameters are available in > # %_, which is structured as follows: > # %_ = ( uri => 'foo', > # method => { name => 'AMethodOfFoo', > # arg => [ 'gaga', '...' ] } ) > return 'warn("method called: ".$_{"method"}{"name"});'. > 'warn("endpoint data: ".$endpoint);'; > } > > The other alternative is to do all work in sub endpoint. Collect all data > via childStruct similar to endpoint___call above. See the docs. > There is one drawback: SimpleTaglib needs perl 5.6.0 or higher. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
