Re: Ax1: making document() calls use files instead of URLs
On Monday, 23. June 2008, Martijn wrote: Hello. Quick question, about AxKit1 - trying to boost performance during the final days the server is running AxKit1. Is there a simple way to make document() calls in XSLT-stylesheets use local files instead of URLs, like AxKit2 does by default? Our stylesheets have a large number of document() calls; hence the server is spending quite a lot of its resources calling itself. A file:// URL should fo the trick. -- CU Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AxKit to AxKit 2? / axkit 1 axkit uris issues.
On Tuesday, 17. June 2008, fess wrote: I have a site that has been running AxKit 1.6.2 for some years now. I have 2 questions: 1. Is there any documentation about the difference between the Axkit 1 and AxKit2? Any how to upgrade, why to upgrade documents? AxKit1 and 2 differ greatly. If you were using custom providers, caching or other AxKit-specific code, then it would mean a major refactoring. If all you do is XSP, XSLT and XPathScript, it should be quite painless, but still some work. Would upgrading to 1.7 solve this problem? [ didn't appear so from the changelog but I will probably try it anyhow, got stuck on something else last time I tried.] should I be upgrading to AxKit 2? I won't address your AxKit1 issue, as I never used axkit:// uris, and it has been quite a while anyways. An upgrade to AxKit2 probably won't be painless, as AxKit2 doesn't have axkit:// uris, or, for that matter, caching by default. This is actually a good thing: AxKit2 is designed to make writing plugins extremely easy, and that way you have full control over what gets cached and when and how. Much cleaner than messing with axkit uris. So, if you can spare some hours to learn AxKit2, go ahead, it's really nice to work with. If you need 2 hours upgrade, and everything is like before, then don't do it. -- CU Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AxKit2 dvelopment
On Tuesday, 17. June 2008, Martijn wrote: Hello all. Since this list has gone rather quiet, I was wondering what the development status of AxKit2 is. While working with AxKit2, I found a few (minor) bugs in the code (e.g. sending multiple cookies didn't work). I thought it might be worth having these fixed in the official code too. Moreover, I changed the code at a few places for my own convenience. Nothing like rocket science there either, but some of these changes (e.g. adding an optional argument to the axkit script, which sets the port for the AxKit server, as to make it easier to run multiple instances of AxKit using the same config file) might be useful for others. When I find the time to, I will work on the wiki too. Cool! Feel free do send svn diffs, I get to work on axkit2 every once in a while, then I can integrate your changes. -- CU Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AxKit2 sessions
On Wednesday, 16. April 2008, Martijn wrote: Just wondering if someone has written something that does session management on AxKit2? Will need to do so, and will try to make it as much like Apache::AxKit::Session as possible, but thought someone else might have done that already. Not yet, AFAIK. Although I wrote (one of) the AxKit1 session module(s), I didn't port that to AxKit2 (which I use regularly). I use the inherent session-id capability of HTTP Digest authentication for identifying users. -- CU Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AxKit2 continuations
On Wednesday, 16. April 2008, Martijn wrote: one thing at a time. Doesn't this mean that it can also do one XSLT transformation or XSP interpretation at a time so if someone requests a 'heavy' page than no one else will be able to access the AxKit server? Right. So keep your XSLT / XSP small. The point of AxKit2 is to make it easy to do application logic in pure perl code (which can use asynchronous processing using pseudo-continuations). That way, the presentation layer remains small and fast. -- CU Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: authenticate plugin
On Freedag, 04. Januor 2008, [EMAIL PROTECTED] wrote: Lo, How do I get at the session data in the authenticate plugin from within my plugin? ie the user name and the session id. Interesting question. I'd have thought I documented that, but if you ask, I guess I forgot that. Are you online somehow/somewhere? IRC/ICQ? With all those little issues, I think we could do a good chat-and-bugfix session. -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ax2: serve_cgi
On Middeweken, 12. Dezember 2007, [EMAIL PROTECTED] wrote: serve_cgi is leaving zombie processes behind. Any ideas how to reap them? I will take care of that, as I am delving the AxKit2 sorce atm. as well. Check SVN in a couple of hours. -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [AxKit1] $r-pnotes-('GLOBALS')
On Maandag, 20. August 2007, Martijn wrote:
[I think this is something specific to AxKit - correct me if I'm wrong
and I should have sent this to the mod_perl list instead. My sincere
apologies in that case.]
I'm (re)writing some old scripts for AxKit1 and realised that I could
make my life a lot easier by setting some variables in
$r-pnotes-('GLOBALS') upon (re)starting Apache, so that they're
available for every request (they do change, but only occasionally).
But when this script is running, there is no $r, so accessing it this
way won't work. But then, the $r-pnotes-('GLOBALS') hash should be
'stored' somewhere, as it is shared between the various instances of
$r that might occur. Any ideas how I can access it from a startup
script?
I assume you are talking about the session plugin, which is indeed
AxKit-specific, although the core of the question is not.
Good question. I think there is no Apache-request() object at that point, but
you might try nevertheless.
A hackish way would be to use the Apache::Session modules directly and bind
session ID '000...' (32 zeroes), that's where GLOBALS is stored. You
should not set crucial variables there, however. If those variables are
critical for your web application, you are better off using a database.
--
CU
Joerg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: hooks
On Middeweken, 04. Juli 2007, [EMAIL PROTECTED] wrote: On 3 Jul 2007 at 18:04, Also Sprach Jörg Walter: On Maandag, 25. Juni 2007, [EMAIL PROTECTED] wrote: I also notice that response sent goes via my code, but when I use the browser back button, Response sent is on the console, but nothing from my hook. Anyone any ideas? A bit late perhaps, but that looks like a HEAD request that doesn't generate any content? It turns out that the back button doesn't actually send anything. Which is a real pain for a web app. It was requesting images, but my browser has no caching so that's probably why. Any idea why my hooks aren't firing? They don't fire through normal use. I've no idea if they should and they're broke or they shouldn't because they are for not so normal requests. The hooks are connect, pre_request and body_data. ISTR body_data firing for the upload file but I'd have thought that connect should fire all the time. Not in the face of keepalive connections. Probably pre_request is likewise, and body_data seems to be fired only when the request contains a body. Matt is really the one who knows best about hooks. -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: hooks
On Maandag, 25. Juni 2007, [EMAIL PROTECTED] wrote: I also notice that response sent goes via my code, but when I use the browser back button, Response sent is on the console, but nothing from my hook. Anyone any ideas? A bit late perhaps, but that looks like a HEAD request that doesn't generate any content? -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ax2 file handling
On Dunnersdag, 24. Mai 2007, Matt Sergeant wrote:
I'd like to clean this up so that it's more provider-like as in
AxKit1... But I'm just not sure exactly how yet. Perhaps via Moe's
message-passing stuff he added in.
Huh? Did I hear my name? :-)
Message passing would work, but wouldn't a separate (nested?) run of
hook_xmlresponse more closely match the semantics of such a lookup? Maybe
even a subrequest-like building of a new client object?
Thinking about it, it might really be a good idea to define some standard
message for document retrieval, plus a subrequest API which can be used from
such a message handler if that much overhead is desired. That way, access
could also effectively be restricted to allowed/defined content, since no
generic lookup is done by default.
Multiple message handlers could coexist, since a return value of DECLINED
works as expected, and an .odt plugin could handle requests like
$client-send('get_xml','odt:Pictures/logo.jpg')
automatically rooted at the current file, and other plugins could handle other
pseudo-URLs, without conflict or the need for a central registry or anything.
--
CU
Joerg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Axkit2 and Apache fop?
On Friday, 26. January 2007 22:50, Wayde Nie wrote: I didn't see anything in the archives, but can Axkit2 be used to process xml into pdf using Apache fop like Axkit1 was able to do? If so, can anyone provide a couple of pointers? I've currently got Axkit2 and fop (and their prerequisites) installed. As far as I know there is no finished code yet. You'd have to write a plugin that calls fop somehow. Writing a simple plugin is easy, it should not take longer than an hour. There is, however, a hidden gotcha: If you've followed the mailing list, it's the same problem as with DBI queries: blocking. fop probably runs for a while, so you can end up blocking the whole AxKit2 server during that time. So while a simple plugin would be enough for development purposes, when you go live you have to enhance that plugin to support asynchronous operation. That's not too hard, we're still talking about no more than 100 lines of code, but it's something to keep in mind. -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ax2: contributing
On Thursday, 25. January 2007 11:10, [EMAIL PROTECTED] wrote: On 24 Jan 2007 at 11:39, Also Sprach Matt Sergeant: On 24-Jan-07, at 10:52 AM, [EMAIL PROTECTED] wrote: Given the above (I presume it's correct) the ways around it are 1) Have a separate DBI daemon that processes requests and uses Danga. In the next release I hope to build a job server for long running things. Ha! when's the next release? :) Not sure how feasible it is, but we'll give it a go. Will it be another ax2 server that essentially does RPC from the main server? Something along the lines of using Danga to listen on a FD (as per the Ax2 docs)? The methods on the main ax2 server then have to have some CONTINUATION jiggery pokery? I guess there will be no way around that part, no matter how you do it. I have been working on a cool solution to that, but for now I still don't know if it will actually work out in a way that is useful. -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AxKit2 Wiki
On Wednesday, 24. January 2007 13:08, [EMAIL PROTECTED] wrote: I think it's been mentioned before either on list or in the docs about where stuff should be installed. I don't think (as apposed to the wiki) that the modules etc should be under a per site directory structure. That makes upgrading more tedious and time consuming. The modules should be installed in the usual perl module area, eg under site_perl. The plugins should be under the AxKit2 directory in a directory called plugins. That makes installing with a make install possible. Well, that's why I mention three methods of installation. No definite consensus has been found yet, however. My personal favourite has been what you describe (and what I present as third scheme), plus a way to have two (or more) plugin directories: global (core) plugins, private plugins and maybe custom system-wide plugins. But I don't have any experience with that kind of setup. Instead, I now know how nicely multiple private copies of AxKit2 work. I like them, as I tend to suffer from update-breakage rather often. In any case, a make install-able AxKit2 would probably be quite useful. But until there is no definite consensus on what scheme to use, I won't advocate one. I like the ideas about SSL using stunnel or squid. Do they work under windows though? I think so, yes. I was under the impression that SSL could be handled via apache and requests passed on the Ax2. Is this possible? Apache is also capable of reverse-proxying, yes. mod_proxy does that, and it is part of the default distribution. Of course this also applies to connections via SSL. I never did that, but it should probably be mentioned alongside the squid instructions. -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Static files and hook_xml_response
On Wednesday, 24. January 2007 13:24, [EMAIL PROTECTED] wrote: I'm still having static files, .js, .jpg etc go through hook_xml_response. I have a test in there that returns DECLINED for such files, but it's a bit of a kludge. Perhaps it should be possible to do it via the config file? I was told it did this some time back but the latest svn (back then) didn't seem to do it. No doubt more PEBKAC than Ax2 though :) Files *.yourDynamicPagesExtension Plugin yourApplicationPlugin /Files or similar. That way, your plugin is only called for the fhiles it actually processes. Check the docs, I implemented Files and Location sections, they should work mostly like Apache. One important difference is that plugins are always called in config file document order (in case multiple plugins implement a handler). -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ax2: contributing
On Wednesday, 24. January 2007 13:29, [EMAIL PROTECTED] wrote: I was wondering if it would be possible to contribute to the project a mysql db app? They don't come more dynamic than a db app :) Did you solve the problem of asynchronous queries? I think that was the main problem last time. You can't do DB queries like you use to do them in mod_perl, because the process may be blocked for several seconds on complex queries. And blocking AxKit2 means _nothing_ is served in that time. -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Static files and hook_xml_response
On Wednesday, 24. January 2007 16:40, [EMAIL PROTECTED] wrote: Ah, that may be my problem, I don't have dynamic page extensions. Below is my config file. Is what I want not possible with this setup? Yes it is. While things may look Apache-ish, we are talking about a perl program. Of course Location and Files also support regexes. So you can match your dynamic pages any possible way. Another approach would be a second Location block, as only one the first match per nesting level is used. Location ^/ecomm/.*\.(js|png)$ Path /ecomm ... /Location Location /ecomm ... /Location I hope you get the idea. Compare the docs regarding these directives, they should be more accurate than my back-of-the-mind recapture. -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AxKit2 Wiki
Hi! I have added frist pages to the AxKit2 wiki located at: http://trac.axkit.org/axkit2/wiki Feel free to add to my effort, explaining your own experiences or trying to understand my explanations. Basically, this is how my server is now running a heterogenous AxKit1/2/PHP SSL-enabled virtual hosting environment. If your setup is likewise reality-proven and differns from what I found obvious, I'd love to read about it on the wiki. -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Axkit2 wiki
On Wednesday, 17. January 2007 21:17, Matt Sergeant wrote: On 17-Jan-07, at 9:34 AM, [EMAIL PROTECTED] wrote: Are we to have an AxKit2 wiki or something hanging off the existing AxKit1 wiki? Not sure - what do you think would be best? I'm thinking start from scratch... I need to either beef up the wiki properly so that we can add accounts for editors, or just go with a different piece of software for the wiki. Matt, trac has a built-in wiki. Why not use that? All in one place. I'd take a user account as well ;) -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Axkit2 wiki
On Wednesday, 17. January 2007 23:44, Matt Sergeant wrote: On 17-Jan-07, at 4:26 PM, Jörg Walter wrote: I need to either beef up the wiki properly so that we can add accounts for editors, or just go with a different piece of software for the wiki. Matt, trac has a built-in wiki. Why not use that? All in one place. I'd take a user account as well ;) Sure - it's all setup already. Does it require accounts for editing the wiki? I think so. I once tried and was asked to login IIRC. -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using methods in one plugin from another
On Friday, 13. October 2006 17:11, [EMAIL PROTECTED] wrote: On 13 Oct 2006 at 10:53, Also Sprach Matt Sergeant: On 13-Oct-06, at 7:39 AM, [EMAIL PROTECTED] wrote: I thought I'd move some code from my plugin and put it into its own plugin. However, the methods in the new plugin need to be used by the first plugin. How do I go about doing this? I presume I need to somehow put the new plugins object ref into $plugin... Could you write a separate perl module and use it in both? Ah, yes. I'll give it a go. I was thinking more in the lines of an actual plugin though. ie set up in the config file and all that. With access to the AxKit2 object etc. I am writing a few methods for xml caching and I thought if it got more configurable etc I would put it in its own plugin so others could use it... Check out the new messaging system that's in SVN. (You should already have it if you upgraded recently). It allows you to register message handlers (callbacks) that can be called from any plugin. See the docs of AxKit2::Plugin for details. -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: xml_response question
On Thursday, 05. October 2006 17:23, [EMAIL PROTECTED] wrote: At the moment I have a line in xml_response that checks the request for ending in css, gif etc so as to return DECLINE and not try and put them thrugh a stylesheet. Is there an inbuilt way of doing this(ie separating ordinary files from xml) or shuld Iwrite a config directive to do it? Something along the lines of IgnoreFiles gif css jpg You can use multiple location blocks, the first match is used: Location \.(gif|css|jpg|png)$ ... whatever normal files should get /Location Location /your_app/ ... your webapp code ... /Location -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: parse_post_param problem
On Thursday, 05. October 2006 17:17, [EMAIL PROTECTED] wrote: On 4 Oct 2006 at 16:38, Also Sprach Jörg Walter: It's the problem of all redirects. Apache is no different. The solution is to try the just discussed way of suppressing the redirects, or to /-terminate the URL right from the start. I can't work out how to suppress a redirect. I have managed to get a / terminate though. A redirect seems to happen when the url is http://domain.dom:8000/foo?fire=hot Right, this is explained in the same mail that mentions 'Path ' as solution. Unfortunately, I forgot to mention that that solution (and the other things I explained today) need the current developer code from SVN. So whatever I explained, it all applies to changes _after_ AxKit2-1.1 http://domain.dom:8000/foo/?fire=hot Is the above a valid url? the / before the ? looks wrong. It's a perfectly valid URL. If you don't want to upgrade, that's the easiest way to go. In the above case a redirect is a waste of time, isn't it? Right. The redirect is done because of the way AxKit2 handles Location blocks, and only in the current development code that behaviour can be changed. What I've done to get round my problem is to have a fixup hook. If the request is a POST, I save the params to cache. If it's a get and we aren't about to redirect, i save the params to the client param api. Is this a valid way to do it? (the best way?) I strongly suggest to upgrade, or if you don't want to, to use URLs ending with / where needed. Both variants are much better than a caching solution. -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: uri to file strangeness
On Wednesday, 04. October 2006 12:31, [EMAIL PROTECTED] wrote: Lo all, There's a bit of a difference as outlined below. It doesn't seem to be causing problems tho. Any url seems to have a / put on the end for some reason. fred is set up in axkit.conf as a location. Locations are usually interpreted as directories. This stems from a fundamental difference between the Apache location mechanism and AxKit2's. In Apache, Location was simply an URI match and had no influence on uri-to-file mapping. In AxKit2, each Location maps to it's DocumentRoot (either explicitly configured for that location, or inherited), so the location is usually resolved to a directory. Example: DocumentRoot /foo/bar Location /baz /Location In Apache, URIs would be mapped this way: / - Dir /foo/bar, URI / /baz - Dir /foo/bar, URI /, path_info /baz In AxKit2, it works like this: / - Dir /foo/bar, URI / /baz - Dir /foo/bar, URI /baz/ because any URL starting with /baz will do path lookups beginngin with /foo/bar again. This is by design, because it allows you to easily share a common web data root among all web applications (which is expected to be the common case). To get Apache-like behaviour, add one directive to each Location-block: Path (It specifies the prefix to be stripped from URIs before filename resolving takes place, so this line disables the AxKit2 mechanism.) -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: parse_post_param problem
On Wednesday, 04. October 2006 16:18, [EMAIL PROTECTED] wrote: Well, I eventually found how to do it, but I now have a problem The log below is from when the submit button is pressed. As one can see, the params username and passwordname are put into the clients param api but then are promptly forgot about due to a redirect. Is this expected behaviour? It's the problem of all redirects. Apache is no different. The solution is to try the just discussed way of suppressing the redirects, or to /-terminate the URL right from the start. Actually, the problem arises from a HTTP misinterpretation. I think (I am not sure) browsers should re-send post data after a redirect, but practically no browser does this (except for lynx or some other exotic beast) for security/convenience reasons. -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: uri_to_file
On Sunday, 24. September 2006 11:00, Lars Skjærlund wrote: However, I might have misunderstood you: When I complained that DirectoryIndex would only take a single parameter - and that I needed more - you answered in two ways: By adding an error message stating that you cannot have more than one parameter, and by telling me that I should use typeless_uri instead. You also assured me that the latter would solve my problem. Well, the error message was not in response to your request. It was part of the config system rewrite. It was an improvement, because previously you didn't get an error message, but still only one DirectoryIndex. Moreover, I suggested you try typeless_uri to see if it suits you. If not, well, it was just an attempt at being helpful. It was not a suggestion that this is the only way to go. But it won't: First of all, I want to use .odt files for ordinary webcontent, and your typeless_uri doesn't allow for that. I could modify How so? What in typeless_uri prevents you from using .odt as extension? it, of course, but then we're back to the old story. But at the same time, simply adding .odt as an extension on your list still wouldn't solve my basic problem, as I would like to be able to add an arbitrary number of extensions for different fileformats - and the crucial problem for me would be that I sometimes need tight control over the order that extensions are checked. So where is the problem? As the documentation for typeless_uri says, the configuration directive URIExtensions configures what extensions to try, and in what order. Apache has worked like this for years, you have the choice and the flexibility to do so if you please, but it appeared to me that your message was: No, either you use a single index file, or otherwise use typeless URIs. Whilst I can follow and sympathise with the latter, it You aren't forced to use typeless URIs for all of your site. While they _are_ an improvement to your site, no one forces you to use them exclusively. If you just need the DirectoryIndex funtionality, go ahead and use it just for that. Any URL that points to an existing file won't be touched by typeless_uri. my $mtime = $client-headers_out-header(Last-Modified) ? $client-headers_out-header(Last-Modified) : http_date((stat(_))[9]); This is obvious and logical, so I have added something like that to serve_file. -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: uri_to_file
On Saturday, 23. September 2006 11:27, Lars Skjærlund wrote: * Are the plugins included with AxKit2 meant as examples only to be modified by the end user, or are they intended as end-user code? If I modify a plugin, won't the modifications be overwritten by later updates? I think of the default plugins as a decent base to get going fast, but not as the one and only way to go. As Matt already said, just rename your modified file and use it. * I've now started writing my own modules that replace the default plugins. Unfortunately, I cannot find a way to let my plugins coexist with the default plugins. Is this a good thing? There is no need, IMHO. The plugin architecture is central to AxKit2 exactly /because/ you are allowed to use your own code for any part of the request. Throw out uri_to_file if you want to do it in a completely different way. * Or would I be better of choosing another server? I surely miss the flexibility of AxKit1 I'm sorry to say. What part are you missing? AxKit2 is way more flexible since it is so much easier to use custom components for almost all aspects. Keep in mind that AxKit2 is still young. It already works great, but I bet there are tons of little features that are still waiting to be implemented. Don't hesitate to ask us for features, perhaps someone is already working on it or wants to work on it soon. -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: uri_to_file
On Sunday, 24. September 2006 02:00, Lars Skjærlund wrote: Nothing cannot be solved - it's just software, and it seems you've uncovered a bug in uri_to_file that needs fixed anyway. What I meant with cannot be solved was that it appeared that you did not want to solve it. While I don't exactly recall the issue you mention, be aware that we don't ignore your feedback. IIRC, Matt explicitly said that we should modify uri_to_file to follow Apache's behaviour. It was just not done yet, since like most open source projects, it is done in spare time. I'm fully aware of that. However, following this advice would mean that next time you update some central parts of Ax2, me as well as my users would miss that update as we're using the non-default plugin. Of course The idea is that plugins are small enough so that it won't hurt you if you use different/older code: For example, server_file works as intended -- it could happen that it is never touched again. If you modify it, you will get a modification of a working plugin. Should we ever update serve_file, you will still have a stable and working plugin. Your site won't break, and if your custom serve_file fulfilled all your needs, it will continue to do so. Of course, should we use your feedback to add functionality you added yourself, you could switch over. But since you were working off a stable version, there is no pressing need. And the changed line? I tried setting the last modified header in my plugin, however, serve_file insisted on loading the mtime from the temp file and overwrite the value I supplied. The result beeing, of course, that browsers would reload the pictures all the time as the temp file would always have a new mtime. I also gave up asking you to change it as I expected an answer along the lines that 'AxKit performs so well that you don't need caching'. Oh come on. You're being unfair. Your expected answer has nothing to do with your problem. I'm quite interested in what you did, maybe the patch is generic enough to be included in the next version? When I replace modules like uri_to_file and serve_file, I think I replace so central parts of AxKit that I may be starting a new development branch - and I don't want that to happen. However, the VDMS As Matt already said, some changes are in fact bug fixes. Send a patch and we will consider it for inclusion. Others are specific to your needs, but as shown above, it doesn't mean you are bad off by forking. You're being a big help in finding the areas of weakness of AxKit2, but you have to weigh that against the fact that you're not playing - you're trying to build something real. Is that to be understood like AxKit2 is simply a playground to try new ideas? Whilst I respect that, it's definately not what I need right now... It means that AxKit2 is still very young. It has a solid base, but only real-world projects can help smooth out rough edges. Our intention is to have a good Perl/XML application server that can compete with Apache/mod_perl. I think the very hardest thing about AxKit2 is the lack of documentation... Where exactly? What questions did occur to you, and where did you look for answers? IMHO, AxKit2 is well documented for plugin authors, it has a number of working examples, it's just not a book. Let us know what problems you encountered, then we can fix it. -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: uri_to_file
On Wednesday, 20. September 2006 17:41, Lars Skjærlund wrote: Hi all, Playing around again, I fell over some other bits whose behaviour I didn't like. If you have a DirIndex like 'index.odt index.html', uri_to_file only reads the first value. My patch makes it multivalued like with Apache and most other webservers I know of. You should have a look at plugins/typeless_uri. Typeless URIs are a Good Thing(tm), and they solve your DirectoryIndex problem as well. -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Serving files
On Sunday, 17. September 2006 09:44, Lars Skjærlund wrote: * But passing it on as you suggested, $hd-filename(\$document), serve_file won't open it. I've added several LOGDEBUGs to serve_file, and it is the open that fails. Can you try modifying the open call to use the three-argument form, i.e open($fh,'',$filename)? Another check would be to see if $filename is still a reference (print the value of ref($filename), it should be SCALAR. -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Temporary data storage
On Monday, 18. September 2006 14:54, [EMAIL PROTECTED] wrote: localhost:8000/emap?rose=encrypted string Where can I put the parameters? Should I 1) Have a my %hash in the plugin? 2) store a hashref in notes 3) something else? Why not decrypt the values and store them in $self-client-param? After that you could use param() as if they were not encypted. -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ANNOUNCE: AxKit2 1.0
On Saturday, 16. September 2006 23:14, Lars Skjærlund wrote: * libferris runs in user space - we want something that runs in system space. When somebody adds additional RDF information, that information should be shared with the entire organization, not kept personal. I don't doubt your reasoning, but I thought I'd mention that user space usually just means is not a device driver / doesn't run as privileged code / is not a part of the OS kernel. You want that. The VDMS you are writing is user space as well, even if run with administrator rights and on a central server. Hope that clears up a misconception. -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AxKit2 on Windows
On Monday, 18. September 2006 16:47, Andrew Davies wrote: So I fall at the first hurdle- I can't get AxKit2 running on Windows. I know it serves me right (:-)), but didn't someone say they'd done this? Although I can't help you with Danga::Socket, I hope you will be running all demos and check that we didn't mess up anything. I have modified several places to make sure AxKit2's usage of path names is system independent. I hope I got them all ;) Please continue to report bugs. -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Serving files
On Saturday, 16. September 2006 12:09, you wrote: Temporary files are implicitly closed when 'you launch another program from within your script', to quote the Camel Book - and with the plugin architecture of Ax2, this seems to be the case. So even though I've tried modifying server_file to accept a filehandle instead of a filename, the filehandle of my temporary file is closed when it reaches server_file. AxKit2 doesn't call any external processes. Plugins _are_ plain perl modules, with a regular package nanme and everything -- we just hide the verbosity from you. There must be a different reason why you see that behaviour. And handing a memory image to server_file means even heavier modification. Actually not -- according to 'perldoc -f open', passing a reference to a scalar instead of a file name will make perl = 5.8.0 read data from that scalar. $hd-filename(\$content) might do the trick. -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Serving files
On Friday, 15. September 2006 12:50, Lars Skjærlund wrote: Do I need to reinvent the wheel, or is there some way that my plugin can pass the file to the serve_file plugin? The file only exists as a temporary file and/or a cached file. I can of course leave the temporary file intact and modify the header, but how do I tell serve_file to clean up then? Modifying $self-client-headers_in-filename is the way to go. You can clean up in hook_response_sent. See perldoc lib/Axkit2/Plugin.pm for a list of available hooks -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Passing parameters
On Friday, 15. September 2006 14:14, Lars Skjærlund wrote: With Ax1, I could pass parameters from Perl code to the XSLT processor and use them in my stylesheets by setting these in the Apache request object - something like: I think you have found the next missing feature. Feel free to implement some way of adding params in lib/AxKit2/Transformer/XSLT.pm if you need it urgently, and send patches ;) Otherwise, if you wait, such a feature will come along as I will need it, too. -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Axkit2 Caching
On Thursday, 14. September 2006 10:43, [EMAIL PROTECTED] wrote: On 13 Sep 2006 at 14:20, Also Sprach Matt Sergeant: [EMAIL PROTECTED] wrote: Is the Cache::Cache stuff in there for us to roll our own caching of html pages or does Axkit2 have that inbuilt? I'm looking for feedback on caching. I got fantastic performance when I benchmarked doing XSLT without caching (just caching the stylesheet forever), How does one cache the xslt stylesheets at server start time? In the current AxKit distribution, stylesheets are cached after the first use. This is a lot like AxKit1, only that due to the single-process model, caching is effective for any and all subsequent requests. You could trigger that caching earlier, but I think it won't make that much of a difference, since only the first request ever needs to parse the stylesheet. -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Providers?
On Thursday, 14. September 2006 13:38, Lars Skjærlund wrote: As you can see, I've tried to handle it directly in my routine, but I've also tried to do it the way you recommended (with a proper change of axkit.conf, of course). No matter what, I get the same error: 10.0.16.50:3220 L3 FATAL PLUGIN ERROR: Entity: line 1: parser error : Document is empty PK ^ I'd also say that you are reading the zip file instead. Try to leave out the seek($fh,0,0), maybe that messes it up. You can also use plugins/demo/moewiki as a base for your plugin, it is a small and working example for various techniques and can serve as boilerplate code. -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: continuations
On Thursday, 14. September 2006 17:16, [EMAIL PROTECTED] wrote: Reading the docs, I've come to the continuation section. Does it only apply to disk stuff or could I write something that handled long database queries, for example? Basically, it's about anything that lasts some time. Regarding database queries in particular, fully asynchronous database operations are in development. If your query actually consists of several queries (so you get a chance to return CONTINUATION in between), you are dead right about continuations. If you have a single long-running query, there is no solution right now, but will be soon. -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Providers?
On Thursday, 14. September 2006 23:03, Lars Skjærlund wrote: Have you printed/logged what's in $document? Yep - it _does_ contain the content of context.xml. Did you try to parse context.xml manually? Maybe there's something with encoding that doesn't work. For example, the Zip module may mess up UTF-8 characters, converting them to ISO-8859-1 or something like that, making things fail later. -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dynamic configuration
On Thursday, 14. September 2006 23:34, Lars Skjærlund wrote: But working with a lot of modules might mean restarting AxKit very often and that might not be practical in a production environment: Would it be possible to add some kind of dynamic configuration to AxKit? Yes, easily. It is possible to have a dynamic loader plugin that handles loading of plugins at runtime, and even reloading them on change. I have rewritten the configuration subsystem, and that will make that task quite easy, because there will be no more difference between the built-in directive Plugin and anything your plugins would like to provide. I'm just waiting for Matt to discuss/review and finally approve it, as it is a major internal change (fully backwards compatible, of course). Perhaps you can write some more about your idea, since I don't yet exactly know what you have in mind. But I am sure it is quite easy for any variant of dynamic loading I can think of. -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dynamic configuration
On Friday, 15. September 2006 00:08, Lars Skjærlund wrote:
It wouldn't be a nice tough if creating a new plugin for a customer
would mean restarting their production server as we expect to have to
create a lot of plugins on a regular basis.
Ah, I get it. Well, I'd do that in a meta-plugin. A auto-filteype plugin
that checks the file type of a requested file, then checks if a plugin for
that file type is installed, and then loads that plugin.
When my config changes are committed, loading and adding a plugin to the
current Location block at a later time would just mean calling:
AxKit2::Client::conf_Plugin($self-config,$name_of_plugin)
Right now I've realized that even changing an XSLT stylesheet means
restaring AxKit - that's too bad, AxKit1 performed better in this
respect ;-).
An interesting remark. I am against automatic dependency tracking like AxKit1
did (because even style sheets can have complex dependencies, and forced
checking can cost a lot of performance), but you are right, there should at
least be an API to manually invalidate cached stylesheets. I'd imagine
something like this at the end of lib/Axkit2/Transformer/XSLT.pm:
sub invalidate { delete $cache{shift}; }
Then you can delete cache entries when you need to by calling
AxKit2::Transformer::XSLT::invalidate($filename);
Perhaps automatic invalidating/reloading is better kept in a
separate development support plugin, because a production server should
never have to re-load anything.
--
CU
Joerg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Providers?
On Wednesday, 13. September 2006 11:15, Lars Skjærlund wrote: Hi list, I'm trying to work my way through the new AxKit2 code - but before I figure it out myself, maybe someone would be kind enough to help me: Where's the equivalent of an AxKit1 Provider? For AxKit2, all you write are plugins. Plugins are documented in AxKit2::Docs::WritingPlugins. The usual hook you'd implement for provider-like behaviour would be handle_xmlresponse, unless you are creating non-XML-content, then it would be handle_response. Basically, there are no providers anymore. xmlresponse hooks are free to read any data from anywhere they like, for examples from the file named $self-client-headers_in-filename (the result of uri-to-file mapping). Then you can store your input data via $input-dom(...). If you return DECLINED after that, you have exact provider behaviour. A second plugin can then pick up that DOM and transform it, like generic_transform which is shipped with version 1.1. I suggest you take a look at demo/moewiki, it is pretty short and demonstrates several aspects of provider and webapp behaviour. -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is AxKit 2 for me (yet)?
On Wednesday, 13. September 2006 19:39, Andrew Davies wrote: Currently our site runs with AxKit 1, a mixture of static XML-XSLT-HTML stuff with a pile of XSP thrown in for the dynamic content. There's a bunch of homebrew taglibs (often ripping stuff from mysql databases), and use of other tablibs such as PerForm, Param, ESQL, Util, WebUtil etc etc. User authentication and session management are built on Apache::AuthCookie and Apache::Session. Currently it isn't bust, so why should I try and fix it... well hey; AxKit 2 is there so why not? So can anyone give some hints as to what I can expect to just work and what else may involve pain? Am I right to be concerned about the user and session stuff? Right. I will write something, that's for sure, and I hope to get some type of session and auth plugin(s) into the core distribution, but it isn't done yet. Cookie support could be a bit rough, didn't use it yet (Matt knows the answer). And as Sebastian said, anything using $r will need to be ported. Usually, that's not a big issue, since most of the info is there, just somewhere else. Perhaps the only major functional difference between mod_perl and AxKit2 is the absence of subrequests. If you need them, feel free to speak about your requirements. On the other hand, XSLT, XSP and Taglibs should work. XSP hasn't seen much testing yet, expecially regarding the above mentioned porting issues in taglibs, but it should be fully functional, any bugs you find are just waiting to be fixed :) I wouldn't port big existing code bases over yet unless you have the time to report bugs and help testing new areas. If you have that time, be our guest :) -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Axkit2 Caching
On Wednesday, 13. September 2006 20:42, Kjetil Kjernsmo wrote: I think that in a pipeline, the possibility of caching all along the pipeline would be nice in some cases, so that certain requests will not be passed all the way down to the DB, even though the served resource is a composite of several components. This is what cachecache can do for you. Sure, you will need to do your own expiry/dependency tracking, but I guess it's not hard for you to implement a generic method to do so cheaply. And cachecache allows you to fully control caching, since it is manual, nothing is cached automatically. All attempts at automatic dependency tracking sooner or later failed in AxKit2, so now you get to do it yourself. But As Matt already said, I'd check if it is really needed. Caching always adds an overhead, and perhaps your bottleneck is somewhere else. I envision that HTTP's caching specification could also be used internally in the pipeline, so that if you suddenly decide to throw a part of the pipe away, the client or a proxy will still see and use HTTP headers for caching. How should that work? Clients cannot be aware of your pipeline structure. I haven't had time to look properly into Ax2, and I now recognize the value of patches more than I did back when I started, but since you asked, then yeah, a caching infrastructure is a very compelling feature... :-) Well... up to now, I'd say no. AxKit2 performance is great, you should really go and check it out yourself. Maybe manual caching is more than sufficient. -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Axkit2 Caching
On Wednesday, 13. September 2006 20:58, Jörg Walter wrote: control caching, since it is manual, nothing is cached automatically. All attempts at automatic dependency tracking sooner or later failed in AxKit2, so now you get to do it yourself. But As Matt already said, I'd check if it I correct myself: ... in AxKit1, ... -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ANNOUNCE: AxKit2 1.0
On Monday, 28. August 2006 09:36, Lars Skjærlund wrote: But what about virtual hosting? I run a webhotel based on AxKit with a lot of virtual servers: With your new architecture, wouldn't that mean running a lot of AxKit servers on different ports, one for each virtual server? And then proxying through Apache in order to get them all back at port 80 - or am I missing something here? I wouldn't describe this as a simpler setup... Well, we don't have it yet, but a very basic vhost plugin would be about 20 lines of code. If I am bored, I may even write it myself. And there are multiple server sections possible in the config, so Matt has probably thought of vhosting already, just some connecting bits are missing. It's really easy to hack on AxKit, check out the docs, AxKit2::WritingPlugins is a good starting point. On the other hand I like the idea (and simplicity) of beeing able to run AxKit standalone: But like Tomcat, maybe we should have both options? It has been discussed to use a scheme like pperl, with a small CGI/mod_perl forwarder that starts AxKit2 if not yet running so it would feel like a single server. Should be easy to do, since others did these things already, and we are talking open source ;) By the way, we're running SuSE Linux and at least with that distro, installing Apache and mod_perl is simply a few clicks with the mouse and you're up and running; it's a long time since I thought installing mod_perl was any hassle at all ;-). The new AxKit2 architecture seems to be a lot more complicated to me - at least when you need some of the more fancy Apache options. Well, AxKit2 only has pure perl dependencies except for XML::LibXML (which is quite common nowadays), so setting it up is extremely simple. Nothing to compile, it just works. perl Makefile.PL; make; ./axkit and you have a running AxKit2 demo server. You could even upload AxKit2 including all dependencies via FTP on you el-cheapo 100Meg webspace-with-perl and run it there. -- CU Moe -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ANNOUNCE: AxKit2 1.0
On Monday, 28. August 2006 09:36, Lars Skjærlund wrote: But what about virtual hosting? I run a webhotel based on AxKit with a lot of virtual servers: With your new architecture, wouldn't that mean running a lot of AxKit servers on different ports, one for each virtual server? And then proxying through Apache in order to get them all back at port 80 - or am I missing something here? I wouldn't describe this as a simpler setup... Well, we don't have it yet, but a very basic vhost plugin would be about 20 lines of code. If I am bored, I may even write it myself. And there are multiple server sections possible in the config, so Matt has probably thought of vhosting already, just some connecting bits are missing. It's really easy to hack on AxKit, check out the docs, AxKit2::WritingPlugins is a good starting point. On the other hand I like the idea (and simplicity) of beeing able to run AxKit standalone: But like Tomcat, maybe we should have both options? It has been discussed to use a scheme like pperl, with a small CGI/mod_perl forwarder that starts AxKit2 if not yet running so it would feel like a single server. Should be easy to do, since others did these things already, and we are talking open source ;) By the way, we're running SuSE Linux and at least with that distro, installing Apache and mod_perl is simply a few clicks with the mouse and you're up and running; it's a long time since I thought installing mod_perl was any hassle at all ;-). The new AxKit2 architecture seems to be a lot more complicated to me - at least when you need some of the more fancy Apache options. Well, AxKit2 only has pure perl dependencies except for XML::LibXML (which is quite common nowadays), so setting it up is extremely simple. Nothing to compile, it just works. perl Makefile.PL; make; ./axkit and you have a running AxKit2 demo server. You could even upload AxKit2 including all dependencies via FTP on you el-cheapo 100Meg webspace-with-perl and run it there. -- CU Moe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AxKit2: Status Update (3)
On Sunday, 13. August 2006 18:51, Matt Sergeant wrote: XSP, XSLT, TAL working. XSP TaglibHelper working. Haven't tested SimpleTaglib yet, but it's there. I am available. Contact me directly, not via the list, if any problems arise with it. -- CU Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: LibXSLT problem (possibly)
On Wednesday, 04. January 2006 23:08, Aaron Steager wrote: in makeforelements.xsl. I did check it and there is only one instance of each template. Also the web files and perl files were pulled over from another AxKit system we have and it all works fine on that one so I think the different versions may be the issue. Hi all, I tracked the problem further and have it narrowed down but not sure what the problem is. I did alot of searching on google and forums to see if anybody encountered this before and I couldn't find any that came close to matching my problem The pertaint info from the error log is [Wed Jan 4 14:52:32 2006] [warn] [client 192.168.2.222] [AxKit] LibXSLT match_uri: /styles/emailalerts.xsl [Wed Jan 4 14:52:32 2006] [warn] [client 192.168.2.222] [AxKit] LibXSLT open_content_uri: /styles/emailalerts.xsl [Wed Jan 4 14:52:32 2006] [warn] [client 192.168.2.222] [AxKit] Style Provider Override: Apache::AxKit::Provider::File [Wed Jan 4 14:52:32 2006] [warn] [client 192.168.2.222] [AxKit] decoding from UTF-8 [Wed Jan 4 14:52:32 2006] [warn] [client 192.168.2.222] [AxKit] [req] File Provider given $r: /usr/local/www/data/mvp/styles/emailalerts.xsl [Wed Jan 4 14:52:32 2006] [warn] [client 192.168.2.222] [AxKit] encoding to UTF-8 compilation error: file /styles/makeformelements.xsl line 8 element template xsl:template: error duplicate name 'make-textfield' compilation error: file /styles/makeformelements.xsl line 66 element template xsl:template: error duplicate name 'make-textfield-ho' compilation error: file /styles/makeformelements.xsl line 123 element template xsl:template: error duplicate name 'make-textarea' compilation error: file /styles/makeformelements.xsl line 170 element template xsl:template: error duplicate name 'make-checkbox' compilation error: file /styles/makeformelements.xsl line 204 element template xsl:template: error duplicate name 'make-selectlist' [Wed Jan 4 14:52:32 2006] [warn] [client 192.168.2.222] [AxKit] [LibXSLT] performing transformation [Wed Jan 4 14:52:32 2006] [warn] [client 192.168.2.222] [AxKit] Caught an exception [Wed Jan 4 14:52:32 2006] [error] [client 192.168.2.222] [AxKit] [Error] Can't call method transform on an undefined value at /usr/local/lib/perl5/site_perl/5.8.7/mach/Apache/AxKit/Language/LibXSLT.pm line 124.\n [Wed Jan 4 14:52:32 2006] [error] [client 192.168.2.222] [AxKit] From: /usr/local/lib/perl5/site_perl/5.8.7/mach/Apache/AxKit/Exception.pm : 9 In emailalerts.xsl I have xsl:include href=/styles/makeformelements.xsl/ ... xsl:call-template name=make-checkbox xsl:with-param name=checknamemonthly_winners/xsl:with-param xsl:with-param name=checklabelMonthly Winner Alerts/xsl:with-param xsl:with-param name=checkvalue1/xsl:with-param xsl:with-param name=checkedxsl:value-of select=monthly_winners//xsl:with-param xsl:with-param name=newline1/xsl:with-param /xsl:call-template to make a checkbox. And if I'm understanding the error it's saying that there are multiple xsl:template name=make- Your XSLT is probably faulty. I have made the experience that libxslt is usually right in saying you do something wrong, although it often fails to be helpful ;) Newer libxslt versions often catch more errors, and what may work in older versions by coincidence may now be wrong. Try commenting large parts of your stylesheets to narrow down the problematic locations. -- CU Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: document() problems
On Sunday, 01. January 2006 04:10, Lars Skjærlund wrote:
xsl:apply-templates select=document('menu.xml')/
it doesn't work: Using Sablotron, the browser just hangs (and, it
seems, AxKit starts eating host memory), using LibXSLT, I get a server
error and the log files yells about a possible loop.
What goes on here? Isn't the above syntax correct XPath? The document
is there and can be loaded in other ways, and you can see from the
logfile that it is indeed the correct document it's trying to parse.
It is correct XPath, but as far as I understand, document() returns a nodeset
of _all_ document nodes. So what you did is to apply your templates to all
nodes at once. What you probably want is to apply your templates to the root
node only.
Example:
node
foobar/foo
barfrob//bar
/node
document() returns something like node.../node AND foobar/foo AND
barfrob//bar AND frob/ AND bar. Applying templates means
processing each node multiple times. In big documents, that could well lead
to what you see, much memory used and recursion limits reached.
Solution: apply-templates select=document('menu.xml')/* /, this will start
off at the root.
--
CU
Joerg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Request for Comments: SimpleTaglib users
Hi!
You may or may not have noticed that AxKit to-be-1.7 has a small
incompatibility with previous versions regarding SimpleTaglib (and taglibs
based on it). If you are a SimpleTaglib user (or if you use a Taglib based on
SimpleTaglib), I need your feedback. If you aren't, you can skip this message
without any adverse consequences.
Imagine a SimpleTaglib-based taglib bound to prefix taglib, with this
example tag:
sub buggy1 : XSP_expr {
return { orientation = 'left' };
}
sub buggy2 : XSP_expr {
my @result = (Dahut);
return @result;
}
Now, imagine an XSP page that does this:
xsp:logic
my $result1 = taglib:buggy1/;
my $result2 = taglib:buggy2/;
/xsp:logic
In previous versions, $result1 would be a hashref and $result2 eq 'Dahut'. A
modification of SimpleTaglib broke that behaviour (yes, it was most probably
me...), so that $result1 is now eq HASH(...). The problem is array vs.
scalar context, and that change was an attempt to make SimpleTaglib dwim.
I have prepared a patch which would do the right thing, and what I originally
intended: $result1 would be a hashref, and $result2 would be == 1 (array in
scalar context), but it would still differ from the old behaviour. As an
example, my own Apache::AxKit::Plugin::Session is affected by both issues,
and was easy to fix.
Moreover, the current situation can only be worked around in XSP code (use
list assignment). Taglibs can't do anything to fix the issue. With my
proposed patch, either XSP can work around the issue, or taglibs can be
properly fixed.
The old behaviour has the problem that wantarray is useless in your taglib.
You can't return different values depending on context.
So my question is: Would you be affected by this? How do you think about the
problem? Would you prefer getting the old (less flexible/dwimmy) behaviour
instead?
--
CU
Joerg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Request for Comments: SimpleTaglib users
On Friday, 19. August 2005 14:41, Christopher H. Laco wrote: Jörg Walter wrote: [snip] So my question is: Would you be affected by this? How do you think about the problem? Would you prefer getting the old (less flexible/dwimmy) behaviour instead? But, had I used SimpleTaglib, me reaction to an incompatable new version is based on one other piece of information: How compatable is AxKit 1.7 compared to 1.6? If there were other sweeping changes, I would just update my stuff and set 1.7 as a PREREQ. But if AxKit 1.7 is quite compatable with 1.6, then I think and imcompatable SimpleTaglib is a bad thing. Well, now that you mention it, there was a grave (and unfortunately unavoidable) change which already massively broke compatibility. OTOH, many people use CVS checkouts, these people would not encounter any significant change. Also, keep in mind that several things have to happen for this bug to show up, and that taglibs are easily fixed. We're talking about changing one line of affected tags, and only few tags are affected. It's really a mess, since there are so many if's and special cases. I'd love to do what I should have done in the first place, and then forget it all. With that said though, AxKit-VERSION is your friend. I assume that it's possible to change one's taglib to work with both 1.7 AND 1.6 AxKit installs? That would perfectly possible, and no need for AxKit-VERSION. The fix would be to replace code like this: return @result; with either: return $result[0]; (if @result only has one element and you were just being lazy), or return ([EMAIL PROTECTED]:$result[0]); XSP pages won't have to be touched unless we keep the current situation. -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Request for Comments: SimpleTaglib users
On Friday, 19. August 2005 17:06, Christopher H. Laco wrote: OK, NOW I'm worried. I never use the CVS version; only the 1.62 version on CPAN. This is especially true on windows for most people where the only version that can install is the 1.62 version from TheoryX. Dare I ask what the breaking change was between 1.62 - 1.7? Sure. Basically, SimpleTaglib uses perl attributes for configuration. The attribute names have been all-lowercase in the first versions, but when running AxKit on newer perls and with warnings enabled, this creates zillions of may conflict with future reserved word warnings. Thus, I prefixed all attributes with XSP_, since perl likes mixed-case attributes better. For compatibility, the old names are still parsed and recognized, but your error log will probably fill up impressively fast. Erm... did I send that last mail to you only? -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AxKit::XSP::Session 0.99 tests fail
On Saturday, 16. October 2004 15:59, Josef Chladek wrote: i tried to install AxKit::XSP::Session (the latest from cpan), but can't get it to install properly, as the test fails and usage of the module produces the following error: Authorization Taglib failed to load: Invalid CODE attributes: XSP_expr You need a recent AxKit version. Possibly even CVS. Unfortunately the old code filled your server logs with lots of (harmless, but annoying) warnings if warnings were enabled. -- CU Joerg PGP Public Key at http://ich.bin.kein.hoschi.de/~trouble/public_key.asc PGP Key fingerprint = D34F 57C4 99D8 8F16 E16E 7779 CDDC 41A4 4C48 6F94 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ANNOUNCE: various AxKit-related modules on CPAN
Hi! After some time offline, I'm back, and I've released a few modules sitting on my HD: Apache::AxKit::Plugin::Session - the (in)famous sendmail of session modules, with lots of bugs fixed, and finally something you've been waiting for: One line instant activation. The docs were massively overhauled, so it should be a breeze to get that working. Tie::SymlinkTree - a persistant storage module using tied hashes/arrays, nested as much as you like, multi-processing safe, fast and scalable. The perfect match for your web prototyping needs. It has limitations, but it's very well suited for typical web development tasks. Apache::AxKit::Plugin::Param::Expr - add XSLT/XSP params by specifying perl expressions to be evaluated Apache::AxKit::Plugin::Upload - add an upload progress bar to your file upload forms, or display progress bars for lengthy processing tasks. Much fun! -- CU Joerg PGP Public Key at http://ich.bin.kein.hoschi.de/~trouble/public_key.asc PGP Key fingerprint = D34F 57C4 99D8 8F16 E16E 7779 CDDC 41A4 4C48 6F94 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache::AxKit::Plugin::Session Problem
On Saturday, 03. January 2004 03:14, Matthew Smith wrote: You need to have the redirect thing. I haven't fully understood how it works but the redirect causes a second request or something like that which allows the plugin to run. The correct config directive is PerlInitHandler Apache::RequestNotes The cvs version (http://cvs.garni.ch) has no dependency on RequestNotes anymore. CU Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BasicAuth $r-prev-uri problem
On Sunday, 28. December 2003 19:44, Kjetil Kjernsmo wrote: Hello again! I got a bit further. I'm using the BasicAuth taglib, but not PerForm (since I still try to keep Perl code out of my XSP). When calling login, I get: [Sun Dec 28 18:20:02 2003] [error] [client 127.0.0.1] [AxKit] [Error] Can't call method uri on an undefined value at (eval 45) line 64. and that line is this: return $r-prev-uri; I suppose there is no previous request in my case, and I suppose it could have to do with that I'm not using PerForm, or that the surrounding taglib is a SimpleTaglib. I don't know BasicAuth, but it seems it expects an internal redirect happening before (that would be $r-prev). My first guess would be a problem with that - configuration error, or bug. -- CU Joerg PGP Public Key at http://ich.bin.kein.hoschi.de/~trouble/public_key.asc PGP Key fingerprint = D34F 57C4 99D8 8F16 E16E 7779 CDDC 41A4 4C48 6F94 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: expr type tags start of block problems (possibly SimpleTaglib related)
On Friday, 26. December 2003 15:52, Kjetil Kjernsmo wrote:
Hi, merry xmas to everyone and thanks for the answer!
On Wednesday 24 December 2003 15:08, Jörg Walter wrote:
This is a problem with XSP itself in conjunction with SimpleTaglib. I
have worked around that by keeping track of STL-tags encountered so
far, but of course this fails when taglibs made with different
helpers are mixed.
I see. To (re)use other people's taglibs, there really is no option but
to mix taglibs made with different helpers
Yeah, it's a limitation that can only be fully fixed by a rewrite of some
parts of XSP.pm. With all these different taglibs and taglib helpers around,
no one really dared to. You'd have the same problem if it were a no-helper
taglib.
[...]
do {
[...]
} ## end do
$parent =
__mk_ns_element_node($document, $parent,
q|http://www.w3.org/1999/xhtml|, q|
strong|);
[...]
and it complains about a syntax error somewhere around
} ## end do
$parent =
I must admit allthough (or perhaps because) I've been staring at this
for hours, I can't actually see the syntax error here, but the whole
do { } requires just like eval { } a semicolon, it is not a block statement
like for { }. So we've changed the problem a little bit. I guess putting a
semicolon at the end of the newly insertes xsp:logic should take care of
that.
--
CU
Joerg
PGP Public Key at http://ich.bin.kein.hoschi.de/~trouble/public_key.asc
PGP Key fingerprint = D34F 57C4 99D8 8F16 E16E 7779 CDDC 41A4 4C48 6F94
Re: Anyone on Debian Sid? (PerlAuth*Handlers problem)
On Friday 31 October 2003 17:57, Kjetil Kjernsmo wrote: On Friday 31 October 2003 12:50, Jörg Walter wrote: I'm wondering if there are any others here using Debian Sid, and if so, is using authentication on the top of the apache-perl package. Use mod_perl as a DSO, that works fine. Package name slipped my mind ATM. Yup, I know, but since mod_perl is so extensively used by AxKit, it would be nice to use apache-perl with it statically linked, and besides, if there is a bug in the package, it should be fixed... :-) Well... I think there is no real benefit of using mod_perl statically linked. I even remember reading somewhere that PerlFreshRestart only works decent if you are using a DSO. And, for that matter, AuthHandlers and everything work fine. Dynamic linking isn't really that much of a performance bottleneck, especially since you have perl code which should make much more difference than the added function call overhead. CU Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Choosing XSL StyleSheet From XSP
On Friday, 10. October 2003 16:21, Gaston wrote: Hi, I am new to AxKit, then there might by points I did not understood at this point. I am testing axkit to rewrite an application already existing in Mod Perl. And I do not know how to implement a quite simple feature. I did not find the answer in docs nor Google. At our Welcome Page say /cgi/index.cgi, there is a Form like this : form action=/cgi/connexion.cgi input type= ... ... /form If the login and password are recognized, the main protected page is displayed. If not recognized, the same login page is displayed with an error message. Using XSP, I do not find a way to display a different page if user is not recognized. And that will be the same for other forms we are using. How are you dealing with that kind of errors? How can we : - either redisplay the form with an error message on bad or missing fields - either display next page. Use a redirect to redirect on success. You may want to check out PerForm as well, it works similarly. -- CU Joerg PGP Public Key at http://ich.bin.kein.hoschi.de/~trouble/public_key.asc PGP Key fingerprint = D34F 57C4 99D8 8F16 E16E 7779 CDDC 41A4 4C48 6F94 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Debugging strange problems, unwanted persistance and similar (was: Re: Provider problems)
On Thursday, 09. October 2003 21:37, Christian Jaeger wrote: - Problem: somehow new requests depend on previous requests. Some state information is preserved between requests. When I request an .xml file as .html, then even subsequent .xml requests yield the .html. In spite of AxNocache On in the apache condig, so it doesn't seem like a cache problem (though that's prolly an unsolved problem still). See http://www.axkit.org/wiki/view/AxKit/DebuggingStrangeProblems -- CU Joerg PGP Public Key at http://ich.bin.kein.hoschi.de/~trouble/public_key.asc PGP Key fingerprint = D34F 57C4 99D8 8F16 E16E 7779 CDDC 41A4 4C48 6F94 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SimpleTaglib question
On Monday, 06. October 2003 04:00, Matthew Smith wrote:
How do you use one simpletaglib from another?
E.g. from my tag handler, I want to set a session variable - so how do I
call session:set-attribute name=cmddoit/session:set-attribute
from a taglib?
To call webutils I just go
AxKit::XSP::WebUtils-redirect($blah);
That doesn't work for AxKit::XSP::Session
There's no easy way apart from what Matt said. The session taglib was written
with the old (current) version of SimpleTaglib, which places the code into
the page and thus doesn't have user callable subs for it's functions. It is a
good idea, however, and I will bear it in mind when finishing up the next
release.
In your case, you may use $r-pnotes('SESSION')-{cmd} = doit; for now.
That's how it is documented in the plugin man page.
--
CU
Joerg
PGP Public Key at http://ich.bin.kein.hoschi.de/~trouble/public_key.asc
PGP Key fingerprint = D34F 57C4 99D8 8F16 E16E 7779 CDDC 41A4 4C48 6F94
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Character Set Problem in ESQL-Taglib
On Thursday, 02. October 2003 09:23, Ralf Ullrich wrote: There is a helper function AxKit::ToUTF8($string) which will convert your data from AxExternalEncoding to UTF-8. Thanks a lot, that works. But then my initial asssumption seems to be rigth: if you dont use ESQL for database access, you have to care about encoding yourself, right? Yup. AxKit::ToUTF8 is just a convenience function which lets you specify the source encoding in a single location (httpd.conf) instead of spread throughout your code. -- CU Joerg PGP Public Key at http://ich.bin.kein.hoschi.de/~trouble/public_key.asc PGP Key fingerprint = D34F 57C4 99D8 8F16 E16E 7779 CDDC 41A4 4C48 6F94 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Character Set Problem in ESQL-Taglib
On Thursday, 25. September 2003 17:06, Ralf Ullrich wrote:
I use AxKit::XSP::ESQL and My::AdressManager (which @ISA
Apache::AxKit::Language::XSP::TaglibHelper) to generate output.
When I use encoding=UTF-8 I get all my umlauts as '?' (using mozilla).
replacing UTF-8 with ISO-8859-1 produces the same result. In my
home-grown AdressManager Taglib I convert the dbdata before presenting
it with something like
s/ä/encode('UTF-8','ä')/, and this works of cource event though I#m
still looking for a better way to do this.
There is a helper function AxKit::ToUTF8($string) which will convert your data
from AxExternalEncoding to UTF-8.
I certainly dont want to do this neither in XSP-pages that use ESQL. The
only thing I can do is to choose a different character-encoding in my
browser, which shows the right result. I know from perldoc that all data
in taglibs is always returned in UTF-8, so it doesnt seem to make any
sense to change encoding to ISO in XSP-Pages, or am I wrong?
Is there anybody on this list who experienced the same problems and
found a working solution to this?
You can try ESQL from CVS. It has experimental support for automatic
conversion of your DB data to UTF-8 (unless it detects it is already UTF-8).
Set AxExternalEncoding ISO-8859-15 (or whatever the correct value is), and go
for it - your data will appear as UTF-8. Note, however, that your DB is
probably going to migrate to UTF-8 over time, as storing back the data won't
convert it back (yet).
--
CU
Joerg
PGP Public Key at http://ich.bin.kein.hoschi.de/~trouble/public_key.asc
PGP Key fingerprint = D34F 57C4 99D8 8F16 E16E 7779 CDDC 41A4 4C48 6F94
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Transformation from multiple sources
Am Monday, 22. September 2003 22:05, schrieb Robert Ferney: I'm not going to pretend to know how things should work here.. however I am assuming that if you use a http://machine/path/filename.ext to specify the results that you desire to include, that you are expecting that the machine server will return filename.ext in the format that it does normally, under the assumption that machine is configured and operates properly. If this is true, then the case where the machine happens to be the same as the one on which axkit is operating, then that same behavior should hold. Yes - if using http. My point is, that a resource usually has many URLs associated to it, and axkit is definitely not accessing resources via http. Every protocol has it's own retrieval semantics. We already are on the server side of the request - local access is local access, and follows different rules than network access via http, even if the machine involved is the same. For the browser, the resource seems to be http://machine/file.ext;. The apache web server translates this request into a local identifier ($r-filename) during the translation phase, and for the local content handler, it is a file resource, not a http resource. Now, for convenience, axkit uses the apache name space (virtual file tree). The 100% correct and consistent solution would be to go where CGI and PHP and all other content handlers go, use direct file access without apache's path translation. It would be a highly consistent behaviour with other content handlers, but would render absolute paths near useless - hardcoding the document root is hardly a good idea. It is well-defined, logical and intentional that AxKit only uses providers to serve scheme-less URLs. Any other behaviour would be inconsistent. As a side note - an alternative to http://localhost/ to get at your CGIs would be to write a CGI provider which executes the given file as CGI. That's fairly easy to do, and shows how powerful the Provider mechanism is - it is a fair replacement for not having insert-your-favourite-content-handler. Via that route, you would even be able to include PHP (using the CGI executable). -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CGI-Parameters in XSL
Am Monday, 22. September 2003 12:55, schrieb Thomas Schindl: Hi, Normally I can read parameters in XSL using something like this: xsl:param name=cgi_param/ But how can I read a param which is created from a multiple-select list, like this: my.xml?val=1;val=2;val=3;foo=bar Does anybody know? Not via the default mechanism. You could write a plugin which sets a param, or use a module which does that from my CVS grabbag you already know :-) -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: StyleChooser/URI phase style picking
Am Thursday, 18. September 2003 02:36, schrieb Arne Claassen: On Wed, 2003-09-17 at 17:00, Tom Schindl wrote: Is it possible that you forgot to add a return 1; at the end of your pm-Module? Tom No. It's there. Don't think it would even successfully require it, if i was missing the 1; Come to think of it.. Maybe it's an overall miconfiguration on my machine. Using AxKit 1.60 on Redhat 9.0 and on every apache restart i get pages of output like this: Check the clock of your machine and the time stamps of your perl modules. AxKit reloads based on modification time. -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: xi:include
Am Thursday, 18. September 2003 16:18 schrieben Sie: On 18/9/03 2:42 pm, Jörg Walter [EMAIL PROTECTED] wrote: Am Thursday, 18. September 2003 15:32 schrieben Sie: For a development site, I strongly recommend AxNoCache on. Yup, that¹s our setup. However we get newsfeeds etc from third parties that are included within our live site using xi:include, the feeds get up dated regularly and its these that I'm having the problems with. At which point are they included? In XML loaded for XSP? Or for XSLT? Or something else? They are included in the parent XML / XSP page, like so; ?xml version=1.0? ?xml-stylesheet href=. type=application/x-xsp? ?xml-stylesheet href=/style/xsl/html/editorial.xsl type=text/xsl? xsp:page xmlns:xsp=http://www.apache.org/1999/XSP/Core; xmlns:Kentucky=http://www.kentucky.com/xsp/Kentucky/; language=Perl channel xi:include xmlns:xi=http://www.w3.org/2001/XInclude; href=/content/news_feed.xml/ /channel /xsp:page Why XSP for that? I don't see any taglib tags. You can use XInclude with plain XML, no XSP needed. And in this case, XSP is the reason why caching is wrong: XSP caches the generated perl code in memory and/or on disk. It only checks the time stamp of the source file, not of included files -- unlike the regular AxKit cache, which checks everything. -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: xi:include
On Thursday, 18. September 2003 18:33, Mark Cance wrote: On 18/9/03 5:17 pm, Jörg Walter [EMAIL PROTECTED] wrote: Am Thursday, 18. September 2003 16:18 schrieben Sie: On 18/9/03 2:42 pm, Jörg Walter [EMAIL PROTECTED] wrote: Am Thursday, 18. September 2003 15:32 schrieben Sie: For a development site, I strongly recommend AxNoCache on. Yup, that¹s our setup. However we get newsfeeds etc from third parties that are included within our live site using xi:include, the feeds get up dated regularly and its these that I'm having the problems with. At which point are they included? In XML loaded for XSP? Or for XSLT? Or something else? They are included in the parent XML / XSP page, like so; ?xml version=1.0? ?xml-stylesheet href=. type=application/x-xsp? ?xml-stylesheet href=/style/xsl/html/editorial.xsl type=text/xsl? xsp:page xmlns:xsp=http://www.apache.org/1999/XSP/Core; xmlns:Kentucky=http://www.kentucky.com/xsp/Kentucky/; language=Perl channel xi:include xmlns:xi=http://www.w3.org/2001/XInclude; href=/content/news_feed.xml/ /channel /xsp:page Why XSP for that? I don't see any taglib tags. You can use XInclude with plain XML, no XSP needed. And in this case, XSP is the reason why caching is wrong: XSP caches the generated perl code in memory and/or on disk. It only checks the time stamp of the source file, not of included files -- unlike the regular AxKit cache, which checks everything. It is an XSP page I removed tags etc to save from posting the entire file to the groups. The tags used by the page are defined as such; channel Kentucky:Login/ Kentucky:Polls/ Kentucky:Chart id=1 items=5 medium=1 genre= alpha= developer= publisher=/ Kentucky:Chart id=2 items=5 medium=2 genre= alpha= developer= publisher=/ . . . So from what the sounds of what you saying if the include is used within an XSP page there is no way round the caching. If you have maintenance scripts as you say, a simple touch on the main XSP file should suffice to have the page reparsed. Alternatively, you may try to include the external data at a later stage. If including it from within an XSP page for example, all included files will be tracked correctly. -- CU Joerg PGP Public Key at http://ich.bin.kein.hoschi.de/~trouble/public_key.asc PGP Key fingerprint = D34F 57C4 99D8 8F16 E16E 7779 CDDC 41A4 4C48 6F94 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Including xml/xsp content stored in a database
On Saturday, 13. September 2003 06:41, Robert Ferney wrote: I'm working on a system where I would like to be able to have blocks of content for the system stored in a database. including logical and form elements.. however, when I use esql tags to retrieve the xml from the database, it comes out with the tags escaped.. This is definatly the desired default behavior, but I kinda need the xml to be xml when I get it out.. any ideas? Look at the Util taglib (AxKit::XSP::Util from CPAN), especially at util:include-expr. It will do what you need. -- CU Joerg PGP Public Key at http://ich.bin.kein.hoschi.de/~trouble/public_key.asc PGP Key fingerprint = D34F 57C4 99D8 8F16 E16E 7779 CDDC 41A4 4C48 6F94 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AxKit::XSP::PerForm and images with IE (Patch)
On Friday, 12. September 2003 10:04, Jonas Oberg wrote: I recently noticed that AxKit::XSP::PerForm (1.83) did not perform well with images as submit buttons and Internet Explorer. This might be a known problem, but in case it's not, I had to apply this patch to make it work well on the browsers I used to test it: This is not actually a IE issue, but specified in the HTML standard. Image submit buttons submit the coordinates where the click occurred. Thanks for the patch! Matt will surely apply it soon :-) -- CU Joerg PGP Public Key at http://ich.bin.kein.hoschi.de/~trouble/public_key.asc PGP Key fingerprint = D34F 57C4 99D8 8F16 E16E 7779 CDDC 41A4 4C48 6F94 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: document() xslt function
Am Monday, 08. September 2003 16:59, schrieb Alex Sergeyev: Oh, Yeah... I wrote my function and registered it in XML::LibXSLT by plugin... That's really cool thing to have so much functions in xslt. Just in case you need some function, consider implementing a function from the EXSLT standard in C and contributing it. libxslt is among the most complete EXSLT implementations available, and there are only very few functions missing. If it helps your own work, help completing it :-) -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ESQL and UTF-8
Am Monday, 08. September 2003 18:14, schrieb Benjamin Boksa: Data coming from the database (MySQL 4.0.13) is not UTF-8 encoded which (as AxKit excepts UTF-8 input) is a problem if it contains Umlaute or similar chracters. ESQL from CVS contains an experimental patch to transparently decode database results from AxExternalEncoding to UTF-8. You may try that and report how it works for you. -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: random  characters
On Thursday, 04. September 2003 22:42, Daisuke Maki wrote: A few months ago when I was having problems with Cache.pm (bah, I forget, but I think it was Cache.pm), a simple use bytes at the top of the module fixed my problems. However, I was told that since use bytes is a perl5.6.1-ism, it can't be used in AxKit... So has this been changed? can we assume perl = 5.6.1 when developing AxKit code? No, but a use bytes or use utf8 can be added in a backwards compatible way, so it is okay to be used, it's just how you add it which decides. (Baud did a preliminary patch I believe, that's why it was okay-ish) -- CU Joerg PGP Public Key at http://ich.bin.kein.hoschi.de/~trouble/public_key.asc PGP Key fingerprint = D34F 57C4 99D8 8F16 E16E 7779 CDDC 41A4 4C48 6F94 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: random  characters
Am Thursday, 04. September 2003 13:13 schrieben Sie: I have two setups which both show the problem when using Safari or MSIE: Setup 1, MacOS X: Perl 5.8.0 installed from source with default options, AxKit 1.6.2 Setup2, RedHat 9; Perl 5.8.0 installed from source with default options, AxKit 1.6.1 That's fascinating. I would have thought the bug is fixed in AxKit 1.6.2. It certainly doesn't appear here. Anyways, I now have an idea what the bug is and how to fix it. Since I can't reproduce it, can you do me a favour and see if it still appears when AxGzipOutput is off (on the AxKit 1.6.2 machine)? Moreover, what does the processing pipeline consist of? (XSP-XSLT? xml-XSLT? or even more?) -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: random  characters
Am Thursday, 04. September 2003 14:33, schrieb Benjamin Boksa: I set AxGzipOutput to off and the problem still appears (after ~10 requests) with AxKit 1.6.2 on MacOS X. The processing pipeline is kind of complicated, so i don't draw but instead try to describe it. I got a XML-Source (a Servlet), which is loaded by a XSP-Page (using util:include-uri). The resulting XML is processed by a XSL-Stylesheet. The output is included into a file using xi:include. This file is included in another XSP-Page (using util:include-file), which also loads several other things (using util:include-uri and util:include:file). As a general note, did you try to use XInclude for all steps? If you are using XSP just because of your util:include-* tags, you may save considerable processing time by using XInclude instead. You can easily include resources via file://, http:// or the recent axkit://. For this specific case, you should definitely try to reduce the problem to a minimal example. Try removing processing steps and includsions until the problem disappears, re-add the last step which makes the problem appear. Try to remove other steps as long as the problem persists. After that, strip all remaining files down to the bare minimum, but be sure to let the problem intact. httpd -X is a great aid in that case, as your problem should appear faster. -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: random  characters
Am Wednesday, 03. September 2003 10:42, schrieb Benjamin Boksa: Just as a littled add-on: I experience similar problems with MacOS X 10.2 (with perl 5.8.0), In my case there is a problem with Umlauts when reloading the page. These characters are always rendered properly (as spaces, not visible characters) when the server first starts up; it's only after a certain time and/or number of accesses that the Â's start appearing. Once they start showing up, they'll alternately appear and disappear when reloading the same page. If your browser == MSIE, then see if your pages are using UTF-8 as encoding. MSIE is notoriously buggy when displaying UTF-8 encoded pages, switching fonts within the session and stuff. If it chooses a bad font, the nbsp character could be the Acircumflex in that font. -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: random  characters
Am Wednesday, 03. September 2003 11:41, schrieb Benjamin Boksa: Hi Jörg, thanks for the answer. I experience the same problem with Safari and on different servers, even though the the encoding is set to iso-8859-1 (not UTF-8). Well, in that case, try to fetch the page repeatedly (with wget or a similar tool), see if the page content differs, and what exactly these differences are. This might need a hex dump to recognize the space characters (I use 'hexdump -C xxx.html' on linux). Then tell us if you found any difference and if so, what they are. -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reinstall problems
On Monday, 01. September 2003 11:30, [EMAIL PROTECTED] wrote: I store xml and other types of documents (text/html, text/plain, text/plain; charset=utf8 etc in directories which are navigated using fancy indexing. The xml documents are rendered nicely, docbook ones using xps and other types using XSLT. For instance http://sigge.lub.lu.se/2002/Master/KATALOG_54.xml However, if I try to retrieve a directory i get an redirect loop. See the result of a head request at the end of this mail. If I request a directory in an area which isn't used together with axkit/mod_perl the result is OK. It is indexed nicely by apache (eg., http://sigge.lub.lu.se/phptest/). Although I've tried my very best to keep things as they used to be, I must have made something wrong, but I just cannot figure out what it is. Are you using SetHandler AxKit for these directories? Then it might be an interaction of AxKit's AxHandleDirs code with apache. Try changing SetHandler AxKit to AddHandler axkit .xml .dkb .xsp and tell us if it works. -- CU Joerg PGP Public Key at http://ich.bin.kein.hoschi.de/~trouble/public_key.asc PGP Key fingerprint = D34F 57C4 99D8 8F16 E16E 7779 CDDC 41A4 4C48 6F94 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problems with XSP
Am Thursday, 28. August 2003 20:01, schrieb Ian Eure: I get a string of heinous errors, which makes me think that not all the XSP-related modules are installed. Yes, sounds like, though... This is the error, along with many of it's ilk: [Thu Aug 28 10:53:17 2003] [error] [client 192.168.128.100] [AxKit] [Error] AxKit::load_module failed: Can't locate AxKit/XSP/Para.pm in @INC (@INC ... this looks like a typo: It's AxKit::XSP::Param, nor ::Para -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache::AxKit::Language::Query
Am Thursday, 28. August 2003 14:28, schrieb Tom Schindl:
Well I need some informations from a database(small part) and some from
XML-Files. If all data comes from a database I'd agree with you. Still
when having data from different sources like I have I think I've the
following possibilities:
1) Using axkit:-URIs = XSP-DBI-XML
2) Using xincludes
3) Embedd my SQL-Queries into XSL with a construct something like this:
--8--
xsl:value-of select=document( 'dbisql:/SELECT_*_FROM_foo' )/test/
Using SQL queries inside URL's is generally considered bad practice - you can
easily get bitten by SQL injection and whatnot. I have a prototype SQL
provider (and a more advanced design which I will release when done) which
lets you access either selected rows of any table you want, or lets you
define fixed queries which you can later retrieve via
document('sql:myquery/2.xml') (selecting row nr. 2 of your query). I can send
it to you if you want to play with that, but you also need to patch AxKit in
order to have the 'sql' pseudoprotocol recognized. The provider is quite
limited, but it seems to fit your requirements very well. Tell me if you want
it.
A more generic version of it will be released later.
--
CU
Joerg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Axkit newbie needing help
Am Saturday, 09. August 2003 21:33, schrieb Nolan J. Darilek: Initially I created related / and children / tags which listed ulink / tags. These tags were included directly into the page source. I'd like to factor this information out into separate files, though, so I created sidebar.xml and menu.xml files which reside in each directory. I can't for the life of me get these included into my pages, though. I've tried !--#include file=sidebar.xml --, etc. but the comments aren't even making it. AFAIK I have SSI set up correctly, XBitHack on and have chmod'd /index.xml +x. Should this be enough to get this working, or am I missing something obvious? Am I going about this the wrong way? SSI is not processed when you are using AxKit. XML has it's own inclusion facility, XInclude. See the excellent XML Reference Card on axkit.org for the standard, tutorials and many more: http://www.axkit.org/wiki/view/AxKit/XMLReferenceCard# -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Chaining
Am Tuesday, 05. August 2003 13:33, schrieb Tod Harter: Add the following to your xsl xsl:template match=* xsl:copy xsl:copy-of select=@*/ xsl:apply-templates/ /xsl:copy /xsl:template In this case the less verbose xsl:template match=* xsl:copy-of select=./ /xsl:template works just as well since it will still match everything. Sorry, but this is wrong. With your experience, you surely know that copy-of copies a whole subtree, and nothing in your template continues processing, so you would bypass most other template rules. Just imagine a XML snippet abc//b/a. A match on a would work, a match on c would not, as the XSLT processor would never get that far. -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: build trouble on RH9
Am Wednesday, 30. July 2003 17:18, schrieb Creighton Higgins: It took two days, but it's working now. There was much backtracking and re-reading, so documenting the experience would probably require a new default RH9 installation to replicate the conditions, and a slower more deliberate/experience second shot at it. The AxKit on Redhat 9 tutorial (http://axkit.org/wiki/view/AxKit/AxKitRedHat9#) was very helpful. I didn't end up having to reinstall Redhat, but Perl had to be built from scratch, as did Apache and mod_perl. Looking forward to doing it again knowing now what I didn't then, and of course taking copious notes. thanks to all who helped (mostly unknowingly), the mailing list gave direction to my efforts. Can you share your notes with others by correcting/extending the Wiki page? (once Matt fixes AxKit.org, that is :-) -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What of AxKit 2.0?
Am Tuesday, 29. July 2003 16:20, schrieb Robin Berjon: Jörg Walter wrote: I have a yet unreleased plugin which adds arbitrary perl expressions as parameters, Is that http://foo.org/bar.xml?ap=system(%27rm+-Rf+/%27) ? No. But exactly this was my motivation. Think: PerlAddVar XSPCacheParam page 'int($apr-param(page))' which makes the param a cache key _and_ assures that it is much less Cache-DoS-prone due to normalizing it with int. If you add a check for some arbitrary maximum and minimum value, you have a non-DoS variant of any parameter. -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What of AxKit 2.0?
Am Tuesday, 29. July 2003 05:56, schrieb S Woodside: What if I don't want to write perl? XSLT is a first-order implementation language for AxKit is it not? If you're doing an axkit site in pure XSLT, parameters would be the only way to supply configuration information straight from axkit to the stylesheets. Still, a plugin would suffice. I have a yet unreleased plugin which adds arbitrary perl expressions as parameters, you could do the same for arbitrary constant values, it's not difficult. I can send you my simple plugin if you want to use it as a base for yours. -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Building applications with AxKit and XSP, in a reusable extensible way...
Am Wednesday, 23. July 2003 18:19, schrieb Michael A Nachbaur:
On Wednesday 23 July 2003 05:04 am, Adam Griffiths wrote:
SNIP
esql:connection
esql:driverPg/esql:driver
esql:dburldbname=axkit/esql:dburl
esql:usernamepostgres/esql:username
esql:passwordpassword/esql:password
esql:execute-query
!-- esql stuff here --
/esql:execute-query
/esql:connection
/SNIP
One suggestion to make your ESQL code less redundant is to put your
connection information in environment variables. For instance, here's a
(slightly altered to protect the innocent) snippet from my httpd.conf:
Oh, since ESQL version $very_latest, you can do this:
esql:connection
esql:pooldefault/esql:pool
esql:execute-query
!-- ... --
/esql:execute-query
/esql:connection
With this in your .htaccess:
PerlAddVar AxESQLPool default Pg 0 dbname=axkit postgres password
(as often as you like)
The parameters are:
- pool name (choose freely)
- transactions (esql:driver transactions=??)
- dburl
- username
- password
Matt, you did release that version, did you? It's in CVS for nearly a year
now.
To use taglibs in general, you can do (or rather, try - I never did it myself)
this:
my $element1 = {
Name = 'esql:driver',
NamespaceURI = 'http://apache.org/xsp/SQL/v2',
Attributes = [ { Name = 'transactions', Value = 'off' } ],
};
my $element2 = {
Name = 'esql:dburl',
NamespaceURI = 'http://apache.org/xsp/SQL/v2',
Attributes = [ ],
}
$e-start_element($element1);
$e-start_element($element2);
$e-characters(dbname=axkit);
$e-end_element($element2);
$e-end_element($element1);
Please tell me if it works if you try it. :-)
And don't hold your breath for AxKit 2.0, it's still some way off. It might
take until after mod_perl 2.0 (final) is released.
--
CU
Joerg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Building applications with AxKit and XSP, in a reusable extensible way...
Am Wednesday, 23. July 2003 18:47, schrieb S Woodside:
What if you build an XSLT pipeline, and then bring in the XSP generated
content at the last stage using a xsl:copy-of
select=document('axkit:foo/bar.xsp')/ call?
If you did that, you could use XSLT-after-XSP directly. axkit: URLs are
tempting, but usually not neccessary. I reccommend to avoid them whenever
possible, just like XSP-after-XSLT. (But for the latter, I know one valid use
case, for the former, I don't)
--
CU
Joerg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: very slow transformation of Docbook-HTML
Am Wednesday, 23. July 2003 21:21, schrieb Brian Acton: I suspect that there's a way to easily make it work via some configuration trick. Maybe symlinks -- I tried that though and couldn't get it to work -- or an Apache directive that I don't know about. But I guess I'll be using LibXSLT for now at least. You should do so anyways - LibXSLT is far more complete and faster. When you begin to try EXSLT extensions, LibXSLT is a real winner. -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Building applications with AxKit and XSP, in a reusable extensible way...
Am Wednesday, 23. July 2003 12:23, schrieb Adam Griffiths: Hi, I've been using AxKit for a while now and I'd really appreciate any ideas or information on the following question. XSP is great for generating dynamic XML documents and it's fast too. It also caches the Perl code necessary to generate the dynamic XML page so multiple requests only require it is parsed once. However as my application grows and has an increasing number of XSP pages I am finding that many share identical code / xsp-xml fragments, which makes maintaining them all is becoming increasingly difficult. Use taglibs or XInclude. If you find yourself reusing similar functional components, make a taglib of them. If you find yourself reusing data components, or lots of data with a little bit of logic, use XInclude. If you find yourself reusing a lot of data, try rearranging things so you do XSLT _after_ XSP. Of course, this combination does not work with logic inside your data. I use XSLT-XSP-... a lot, but as you already recognized, it's darn slow. For the caching behaviour you suggest you will have to wait for AxKit 2.0. It will most probably have that flexibility. -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can't get Apache::AxKit::Plugin::Session to work...
Am Wednesday, 23. July 2003 14:11, schrieb Misha Kapushesky: Unfortunately, I don't have any one specific question to ask. I've been working for about a week and a half on getting A::A::P::S to work Sorry for that. I feel a bit embarassed that A::A::P::S keeps being difficult. So my question is, basically, how do I set up cookie-based session management together with a login/logout page for a specific directory under my apache web server? Well, first of all, you should always use the Cookie+URL mechanism, as the current implementation fails (with infinite redirects, see below) if cookies are used and the browser doesn't accept them. I got this far: 1. I got session id's to work (but for some reason cannot get cookies to be produced - trying to set up settings like in the docs causes infinite redirects, etc.). So, any help here will be appreciated... Ideally I'd like sessions to be used with Double check your browser settings, development webserver config and so on - I regularly see URL sessions in use with my own development setup, although on the live site, cookie sessions are used. I think it might have something to do with the finer details of cookies and browsers, possibly a browser bug, a A::A::P::S bug or even behaviour that is correct (though annoying). 2. I got the axkitdemo auth.xsp to work. Yay. It adds, sets, removes access, displays permissions (knows about my require user settings from httpd.conf) and knows how to encrypt passwords. This is worth a lot - it means you have everything important working. So, the final question -- can someone post an example _setup_ for this sort of situation? Including httpd.conf, login.xsp and logout.xsp (the latter not as necessary). I've created this page: http://www.axkit.org/wiki/view/AxKit/ApacheAxKitPluginSession I have not tested it, however, but adapted it from a working site. Please report success or failure, and feel free to add more examples if you get other setups working correctly. -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: User/Group/Permissions
Am Thursday, 03. July 2003 22:37, schrieb Robert Ferney: I'm working on several web applications and I would like to be able to slap into my web apps a module to handle the management of the users. IE: I'm lazy and time constrained don't want to have to write more of this than I have to. I've seen a couple 'Session' modules on CPAN, however, I would like some feedback as to what works, and what is good.. You can use straight Apache::Session and it's support modules, then you're doing session management outside of AxKit/XSP. You can use AxKit::XSP::BasicSession (or whatever it is called) for simple session management, but no auth, AFAIK. Finally, you can use Apache::AxKit::Plugin::Session, which tends to be a bit confusing for first-time users (as you already have experienced, sorry for that), but allows you to do everything Apache::Session does, plus everything else under the sun. (Yes, even check if the user is allowed to cook coffee :-) I will try to help you with any issues, but sometimes it might take a week before I have time to read the mailing list. Sorry :-) -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: processing instruction question
Am Wednesday, 25. June 2003 22:39, schrieb Matt Sergeant: On Wednesday, Jun 25, 2003, at 16:09 Europe/London, Ken Burcham wrote: I feel like I'm simply missing something here. Is there some easy way to do what I'm trying to do? You want AxAddDynamicProcessor. I agree with Matt, put your view selection into a AxAddDynamicProcessor module is the clean and probably better cacheable way. But for completeness, there is a second alternative: Put all your stylesheets in a pipeline, or maybe even import them into one big Stylesheet, each one matching on the root some special tag, attribute, namespace or whatever. This way, only the one stylesheet which applies to the current view will be executed, the other ones will not match and given a decent pass-through rule, not have any effect. -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AxKit and Perl 5.8.0
Hi! I've commited patches to ESQL and AxKit regarding UTF-8 and Perl 5.8.0. Anyone using Perl 5.8.0 please check if AxKit works okay for you, especially when using accented characters. These patches _should_ not change anything for Perl 5.8.0, but I'd be glad if you checked that, too. For using a legacy charset with UTF-8 (which more or less everyone does), see AxExternalEncoding. Setting that option will enable automatic translation for your charset, and it will auto-detect if data is already UTF-8. AxExternalEncoding currently has effect on ESQL (reading only), file system access (file names, not contents), and URL translation. -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with xsl:processing-instruction...
Am Tuesday, 10. June 2003 04:00, schrieb Jeremy Frumkin: I have an XSL file which adds a processing instruction to an XML file. I would then like AxKit to follow that processing instruction on the new document, but AxKit does not parse the newly created file to process the in-line instruction. I am adding: xsl:processing-instruction name=xsl-stylesheet xsl:texthref=somestylesheet.xsl type=text/xsl/xsl:text /xsl:processing-instruction This yields an XML document with the 2nd line being: ?xml-stylesheet href=ToLNetscape.xsl type=text/xsl? This should then cause the new XML file to be processed with the new processing instruction, no? Sorry to disappoint you, not it should not. AxKit's pipelines are static, you can't change them halfway through. There are several ways to deal with that, for example by using the various AxAdd*Processor directives or one of the StyleChooser plugins available as part of AxKit and on CPAN. -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: newbie needs help with TaglibHelper
Am Thursday, 05. June 2003 23:33, schrieb Matt Sergeant:
On Thu, 5 Jun 2003, Scott Turner wrote:
I just started using AxKit this week and I've been trying to develop a
tag library that performs a simple MySQL DB query and returns the output
in XML. Whenever I try to run the XSP page which accesses the taglib, I
get the following error:
[Error] Can't locate object method register via package
EEIT::PeopleTaglib at
/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Apache/AxKit/Lang
uage/XSP.pm line 203.
Here's the code for the taglib itself (EEIT::PeopleTaglib):
Does the module compile?
Also you seem to be mixing metaphors - the sub attribute stuff is from
SimpleTaglib, and the @EXPORT_TAGLIB is from TaglibHelper.
It looks more like a misunderstanding:
Scott put the as_xml=1 stuff into @EXPORT_TAGLIB and (I guess) thought that
the sub definition must look the same.
Scott, make a plain sub declaration, just sub record {, that's all you need.
--
CU
Joerg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: XInclude with AxKit
Am Thursday, 05. June 2003 01:51, schrieb Tod Harter: Yeah, the problem is that XML::LibXML requires a flag to be set when the parser is instantiated to tell it to process xincludes. I made a patch to set the flag, but I never did get it to work. The result is that in STATIC xml pages (non-XSP) AxKit DOES process xincludes, but in XSP land it doesn't. I don't know what AxKit you are using, but all my AxKit installations definitely do XInclude for XSP, I use it all over the place. What I'm trying to do is break up components of a page into small parts each of which I can manage the ACL for seperately and have a single xsl sheet control how those parts are arranged within a whole, with the possibility that, based on the data from the XSP, some parts may or may not be included. I thin for your case you should look at XSLT's document() function, it might be better suited. XInclude is always unconditionally - even if you put some xsl:if around it, the document will be parsed and processed, the result is just passed on or it isn't, but it is there. With document(), you won't touch any document unless you actually need it. Moreover, document() has nice semantics for relative paths, once you understand them ;-) -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SimpleTaglib help requested
Am Wednesday, 28. May 2003 19:04, schrieb Christopher B. Liebman:
I'm putting a DB application togeather and am creating my own taglib
specific to the app. I want to have a set of tags like: (these are not the
exact tags I want, just something to get the idea across)
tag:items
xxxtag:value name=xxx/xxx
/tag:items
I want the tag:iems to loop over a set of wors returned from the database.
I have played around with this a bit and have not been successful getting
anything but compilation errors with my attemps to loop. Has anyone done
anything lke this with SimpleTaglibs?
You could do it roughly along these lines: (this assumes you have $my_sth
already set up and executed correctly - if not, do so right in front of the
while)
sub items__open {
return 'while (my $my_database_row = $my_sth-fetchrow_hashref) {';
}
sub items {
return '}';
}
sub items___value : attribOrChild(name) {
return '$my_database_row-{$attr_name}';
}
--
CU
Joerg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Berkeley DB XML
Am Friday, 30. May 2003 23:47, schrieb John Merrells: I'm working on an open-source embedded native XML database project called Berkeley DB XML. I think there would be a lot of value for end users if AxKit were able to run on top of dbxml. We offer reliability and recoverability through transactions, and provide high performance indexing and querying of XML data. Is this something of interest to you AxKit users/developer? Can we collaborate on this? I have already written an XML::DB provider for AxKit for a past project and used it semi-successfully (performance was way too bad, unfortunately). It uses the XML::DB perl module suite, which doesn't yet have an bdbxml driver. After evaluating bdbxml, we switched over to SQL with a mapping layer since at that time bdbxml's indexing didn't work as expected/didn't have the needed performance impact. As for the second way of integrating bdbxml (see Kip's Post), I did not create a XSP taglib but have some infrastructure in place, so it should not be much of a problem. I'd love to see bdbxml supported by AxKit and offer my little time for the AxKit side of things - especially since things are basically there, but I didn't yet look into the perl API of bdbxml (it didn't exist last year). What bothers me a bit is the inefficiency of serializing a query result to a string to get it parsed by libxml as this is our XML library of choice. I have once read on the ML that there is a theoretic possibility to exchange the XML parser library in bdbxml, but how much work would that be? -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
