From: "Tod Harter" <[EMAIL PROTECTED]>
> 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). I think part of the problem here might be that you're trying to make TaglibHelper fit your preconceptions, rather than working within its own worldview in the more complex cases. In this particular case, the original poster wants to have the outer tag's function called *before* the other ones. I have all kinds of responses to that. The first is "why?". I don't know why anyone would want to order their function calls by the hosting server instead of by function. I would think it would make more sense to identify the proxy and uri during the <soap:method> call, or otherwise to provide somewhere else a mapping between method and proxy/uri combination (I would prefer the latter, as it leaves that sort of configuration in a config file). The second response is "why not view call and method as arguments to an endpoint function?" This function could take hashref arguments that identify uris to hit and functions to call. We do that kind of thing here when we're describing complex forms (with our internal forms library). That said, I should point out that TaglibHelper has worked out well for us for, at a guess, 30 modules. Only one of them needed the extra freaky stuff we added for the forms library. The hit rate worked out well for us here. > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
