On Thursday 31 January 2002 18:49, you wrote: > 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.
Maybe so. I don't claim to have worked out all the ramifications of things. As an old line FORTH hacker though I have a lot of experience with run-time vs compile time behaviour stuff (you'd have to know FORTH to understand why...). This is a vary analogous situation. Sometimes I miss FORTH... ;o). > > 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). I can tell you exactly why things need to be ordered that way. It might not seem right on the surface of it, but the problem is that its expensive with some protocols to establish the initial connection, so you don't want to be doing that for each method call, you need a SCOPE in which the connection is valid and a handle is held, so there needs to be a setup block of code BEFORE any calls are made and then a tear down afterwards. In our case we have SOAP doing object activation/deactivation and remote garbage collection, so once the handle to an object goes out of local scope remote garbage collection is triggered (via DESTROY). Database handles are an analogous situation. I expect that the ESQL taglib needs to construct them in the STARTING part of its tag sets, not later on (though one could devise ways to defer things). > > 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. I think it will work out ok for us too. I wasn't trying to knock it. > > > 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]
