Re: axkit2 TAL errors
On Monday 09 February 2009, Harry Wozniak wrote: > At Transformer/TAL.pm line 45 it Carp::Croaks with > compilation error: file unknown-1a5d8f0 element param element param > only allowed within a template, variable or param > compilation error: file unknown-1a5d8f0 element choose element choose > only allowed within a template, variable or param > compilation error: file unknown-1a5d8f0 element otherwise element > otherwise only allowed within a template, variable or param > > However, I can create a separate file that is the xsl from __DATA__ > and transform index.xml on the command line with no problems. It works fine here, even in AxKit. So I can't reproduce this. Which version of XML::LibXML, XML::LibXSLT, libxml and libxslt are you using? Did you try upgrading them all? Are there by chance multiple versions installed, and XML::LibXSLT uses an old one? -- CU Jörg - To unsubscribe, e-mail: axkit-users-unsubscr...@axkit.org For additional commands, e-mail: axkit-users-h...@axkit.org
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 diff"s, 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 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: 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: 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: AxKit::XSP::WebUtils::redirect causing (many) warnings in error_log
On Dingsdag, 27. November 2007, Martijn wrote: > index.xml FWIW, redirect URIs must be absolute to be RFC-conformant. Pretty much every user-agent copes with relative ones, but well, standard is standard ;) -- 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: 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 and also support regexes. So you can match your dynamic pages any possible way. Another approach would be a second block, as only one the first match per nesting level is used. Path /ecomm ... ... 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]
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 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 :) Plugin yourApplicationPlugin or similar. That way, your plugin is only called for the fhiles it actually processes. Check the docs, I implemented and 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: 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]
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 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: 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: Danga and aio
On Tuesday, 09. January 2007 16:18, [EMAIL PROTECTED] wrote: > Is there a quick and easy way to find out if the kernel supports aio? All moderately recent linux kernels should support it. If your system is running on OS software (kernel, libc) from the past 2 years (at least, proably even longer), it should work. -- 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: 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 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: 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: ... whatever "normal files" should get ... your webapp code ... -- 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 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, was simply an URI match and had no influence on uri-to-file mapping. In AxKit2, each 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 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 -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: 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 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 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 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: 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: 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: Temporary data storage
On Monday, 18. September 2006 14:54, [EMAIL PROTECTED] wrote: > > > localhost:8000/emap?rose= > > > > > > 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: 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: 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: 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: 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: Dynamic configuration
On Friday, 15. September 2006 00:42, Lars Skjærlund wrote: > You go to a customer's place. They've asked you to create a new > plugin/transform set based on an extract from some database. You create > a taglib, and then you have to create the stylesheet for the printout. > The customer has very definite requirements and you have to test and > test and test. Unfortunately, this is a small customer with only a > single AxKit server and no economy for creating a test environment - and > you cannot test at home as you don't have access to the database in > question. There is always enough economy for a test environment with AxKit2, because it is so lightweight. Imagine we had that "developer_support" plugin I envision, and Matt's cmd_reload console command. Two instances of AxKit would run off the same file tree, but only the test server would pickup changes automatically (because of the hypothetical "developer_support" plugin). When tests show you can activate the current set of changes, reload all relevant data in the main server through the console without restart. No need to have continuous dependency tracking on the production server, while having full development comfort. -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dynamic configuration
On Friday, 15. September 2006 00:31, Matt Sergeant wrote: > Jörg Walter wrote: > > Perhaps automatic invalidating/reloading is better kept in a > > separate "development support" plugin, because a production server should > > never have to re-load anything. > > Again, this should go into the console, where cmd_reload would reload > all plugins, and clear all caches. Well, having a kind of semi-automatic depenedency tracking for development would be a cool plugin. The use case I have in mind is fine-tuning a presentation style sheet, testing lots of small changes over and over again. Being able to "just reload" would be nice, since when you try 3 changes per minute, typing a command in an extra window is a lot of work. Of course, if no one else does it, sooner or later I will scratch that itch ;) -- 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 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: 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: 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: 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 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: 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: 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: 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: 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 13:17, [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? AxKit2 apps are not epected to do any wholesale caching like AxKit1 did. Large scale AxKit1 users usually put a squid as caching reverse proxy in front of AxKit1 anyway, and that approach is recommended if you need this kind of allround caching. The cachecache plugin is meant for situations when you find out that some step in your application is really expensive (an example is image scaling in demo/gallery) so you selectively cache only those parts that are actually slow. Be aware that we may change the caching API at some time in the future, baud isn't too happy with cachecache as it is now. On the other hand, since we have that flexible plugin system, if you are happy with cachecache, no one will stop you from using it from now on until eternity ;) Another strategy to improve performance is to do some processing at application startup. Since AxKit2 is a single-process server, you can easily parse stylesheets or do other expensive tasks before requests are coming in. By the way: serving static content is extremely fast in AxKit2. C-based servers probably beat it, but no one serves files faster in pure perl. -- 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: Axkit2, sawa
On Tuesday, 12. September 2006 17:50, [EMAIL PROTECTED] wrote: > I'm about to start a new project. I'm currently using SAWA and axkit, > but I'm really only using SAWA for the style choosing and for parsing > the client uri. > > The question is, do I need SAWA with Axkit2? I'd suggest "no". Download AxKit2, copy etc/axkit.conf.sample to etc/axkit.conf and run "./axkit". Connect to http://localhost:8000 and check out the examples. Compare them to the actual source code used, living in plugins/demo/, and you will see that it is probably easier to use pure AxKit2. When you are convinced, look at the docs (also available through the demo setup, first link) and get going ;) -- 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 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: 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 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: 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 > > > ... > > name="checkname">monthly_winners > Monthly Winner > Alerts > 1 > select="monthly_winners"/> > 1 > > > to make a checkbox. And if I'm understanding the error it's saying that > there are multiple > > > 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: > > > 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: bar document() returns something like "..." AND "bar" AND "" AND "" 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: , this will start off at the root. -- 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: 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]
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:
my $result1 = ;
my $result2 = ;
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: 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]
Re: AxKit::Plugin::Param::Expr
On Friday, 15. October 2004 11:58, Richard Lewis wrote:
> Hi there,
>
> I'm just trying out this AxKit::Plugin::Param::Expr module and was
> wondering if there's any way of doing this:
>
> httpd.conf:
>
> ...
> RewriteRule ^(.*) /$1 [E=SECTION:$1]
> ...
> PerlAddVar AxParamExpr section SECTION
> ...
>
> i.e., can I pass a (user-defined) Apache environment variable to
> AxParamExpr? (Of course, my syntax might not be rightsorry)
Should work with:
PerlAddVar AxParamExpr section $ENV{SECTION}
remember, the right-hand side is a plain perl expression. If this example
doesn't work, you can easily access $r for the env var.
--
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: Apache::AxKit::Plugin::Session Problem
On Wednesday, 31. December 2003 16:40, Streph Treadway wrote: > Hi, all, > > I have been playing with the example given in the AxKit wiki for > Apache::AxKit::Plugin::Session and have run into a couple of problem. > > First, I have been unable to make > ErrorDocument 403 /redirect?url=/login.xsp > redirect a request to my login page. I looked over the list archives > and saw that I was not the firs to have this problem. Adding > > > PerlInitHandler RequestNotes > > > did not work for me. I still get plain old 403 errors when I try to > access the protected directory. > > I changed to: ErrorDocument 403 /login.xsp It seems that your Apache/mod_perl isn't processing the configuration instructions that A::A::P::Session issues. I have seen this, but not lately and thus can't verify the reason. Can you tell me your exact software versions? (apache, mod_perl, axkit, A::A::P::Session) -- 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: 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 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: Install He11
If you have mysterious problems, always check with xsltproc. Error-reporting is not always what it should be, and my guess is an error in your XSL. -- 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 Monday, 22. December 2003 18:52, Kjetil Kjernsmo wrote: > I can see that it chooses this based on what the name of the parent was, > but that's where my understanding stops, how are these things assigned when > it comes to taglibs? What is it that can make the name wrong, so that the > wrong string is appended to the script? > > Can anybody enlighten me? 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. Try putting a around the auth tag. -- 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]
XSP problem fixed
Hi! I don't recall who it was, but someone reported a problem with a supposedly not found cache_params error message from XSP. It may have been due to a bug I fixed in CVS right now (and which doesn't exist in the latest release, it was just in CVS), so to whoever it was, please try latest CVS and see if it works now. CU Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: Anyone on Debian Sid? (PerlAuth*Handlers problem)
On Friday 31 October 2003 12:22, Kjetil Kjernsmo 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. CU Jörg - 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: 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 : > > > ... > > > 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]
Re: Can't locate object method "cache_params"
Am Tuesday, 07. October 2003 11:50, schrieb Benjamin Boksa: > Hi List, > > while working on a site completely driven by AxKit I get a lot of > errors like the following: First fo all, which version of AxKit are you using? Tha last release? from CVS? And if so, from when? > Can't locate object method "cache_params" via package > "Apache::AxKit::Language::XSP::ROOT::www::frontend01_2eshoppingscout24_2 > ede::www::web::suche::eingabe_2exsp" (perhaps you forgot to load > "Apache::AxKit::Language::XSP::ROOT::www::frontend01_2eshoppingscout24_2 > ede::www::web::suche::eingabe_2exsp"?) at > /usr/local/lib/perl5/site_perl/5.8.0/i686-linux/Apache/AxKit/Language/ > XSP.pm line 179. I remember having seen those errors sometimes, too. I do not recall exactly what I did to make them go away, but I think it had something to do with subtly invalid XSP content. Try setting "AxTraceIntermediate /some/writable/path", then fetch the pages until you get the error, then look at the .XSP file located in that path - check if you see anything strange. -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PHP-generated XML and AxKit
Am Wednesday, 08. October 2003 00:32, schrieb Kip Hampton: > Your choices are: to wait for AxKit to work under Apache/mod_perl 2.0 > or, if you're the adveturous type, to write a custom AxKit Language > module that calls out php as a binary [1] and forwards the data to the > next processor in the chain (the XSLT stylesheet in your case). The > former is likely a couple of months off... as for the later.. well, > being able to give folks that want it access to PHP as an AxKit Language > module seems like a really interesting feature in any case (assuming it > can be done sanely). I would think it is doable sanely - after all, the command line version of PHP is intended to work via CGI, and we can perfectly emulate a CGI environment - we might even have %ENV already set up correctly. -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Process external data in AxKit?
On Monday, 06. October 2003 12:26, [EMAIL PROTECTED] wrote: > Hello, > > First of all, sorry for posting this twice eventually. I used the wrong > email address, which is not registered on this list. > > Now to my question: Is it possible to read data from an external source > to do further processing in AxKit? Could be for example an RSS file > from slashdot.org or any XML-file from a Domino server or whatever. > Cocoon provides such a facility by using: > src="http://server/database.nsf/XML/blabla.rss?OpenPage"/> > > Is there something similar in AxKit? I don't know what exactly you have in mind, but it sounds like a job for good old XInclude. Basically it goes like: http://server/xml-file"/>, but see the AxKit Quick Reference Card for details - http://axkit.org/wiki/view/AxKit/XMLReferenceCard XInclude also gives you the ability to select a subset of that document using XPointer (which is similar to XPath and also explained on the quickref 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: 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 doit
> 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: Generalizing AxKit::XSP::Param names
On Sunday, 05. October 2003 05:45, S Woodside wrote:
> Yes indeed? What is it? =) I am very interested and hope I can use it
> using AxKit and pure XSLT!
No, it's an XSP extension, not XSLT. We are thinking about making interpolated
attributes (the new value="{$expr}" usage) usable for taglibs - somehow.
--
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 server will return filename.ext in the > format that it does normally, under the assumption that is > configured and operates properly. > > If this is true, then the case where the 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 . 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: Transformation from multiple sources
Am Monday, 22. September 2003 17:43, schrieb Tod Harter: > On Sunday 21 September 2003 10:36 am, Jörg Walter wrote: > > Exactly, AxKit parses the file as file. AxKit doesn't execute CGI's. > > Using axkit:// URLs, you can execute other AxKit pages and include the > > results, but I think this won't work with CGI. You may try > > http://localhost/gcgi/left.cgi instead, which will ask your apache via > > HTTP. > > Its not a matter of AXKIT executing a CGI, its a relative URL, so presuming > the base points to a server where the URL is valid then the results of CGI > execution SHOULD be returned, thats only plain sense... Sorry, but this is nonsense - doubly so. First, "the base" as you call it is only vaguely defined. If you define it in the 'xml:base' sense, then AxKit is 100% correct - within the processing pipeline, the base is a file path, not a http URL - we are inside a server side framework, not inside the browser. Second, even if the base was an URL, CGI's need not be executed. It is up to the http server to do with the CGI's whatever it likes. You cannot point to some resource via http and tell "please deliver the file executed as CGI". -- 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: > > > 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: Transformation from multiple sources
On Saturday, 20. September 2003 14:35, Tod Harter wrote:
> Well
>
> I see what you mean, though its odd that the error you get is EXACTLY what
> I get when I need node-set(). I think that the problem may be that you
> cannot say "document('/gcgi/left.cgi')/" because the result from document()
> is a result-tree-fragment. Honestly it seems like result-tree-fragments in
Sorry, that's wrong. Read the specs, the document() function returns a
perfectly normal node set.
however, Vaclav's suspicion is right:
> On Saturday 20 September 2003 04:18 am, Vaclav Barta wrote:
> > On Saturday 20 September 2003 12:10 am, Tod Harter wrote:
> > I think the problem is that AxKit fails to parse /gcgi/left.cgi because
> > it reads it as a file. Is there some configuration setting (I thought
> > about AxStyleProvider but which provider should I use?) making AxKit to
> > go through Apache when fetching URLs?
Exactly, AxKit parses the file as file. AxKit doesn't execute CGI's. Using
axkit:// URLs, you can execute other AxKit pages and include the results, but
I think this won't work with CGI. You may try http://localhost/gcgi/left.cgi
instead, which will ask your apache via HTTP.
--
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: 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; > >> > >> > >> > >> > >> > >> http://www.apache.org/1999/XSP/Core"; > >> xmlns:Kentucky="http://www.kentucky.com/xsp/Kentucky/"; > >> language="Perl"> > >> > >> > >> http://www.w3.org/2001/XInclude"; > >> href="/content/news_feed.xml"/> > >> > >> > > > > 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; > > > > > developer="" publisher=""/> > 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: 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; > > > > > > http://www.apache.org/1999/XSP/Core"; > xmlns:Kentucky="http://www.kentucky.com/xsp/Kentucky/"; > language="Perl"> > > > http://www.w3.org/2001/XInclude"; > href="/content/news_feed.xml"/> > > 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
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? -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache::AxKit::Provider::Filter and setting styles
Am Thursday, 18. September 2003 01:03, schrieb Arne Claassen:
> Is it possible to have an Apache::AxKit::Provider::Filter handler set
> the styles for the output it's passing along?
>
> I.e. currently my handler does something like this:
>
> my $stylesheet = ' type="text/xsl"?>'; if( $q->param( 'raw' ) ) {
> undef $stylesheet;
> }
>
> $r->print( <<"XML");
>
> $stylesheet
> $xml
> XML
>
> return OK
>
> Is there a cleaner way to setting the stylesheet in this handler than
> printing it to the XML?
Yes there is, subclass Apache::AxKit::Provider::Filter and override the
get_styles subroutine.
--
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]
SimpleTaglib enhancements
Hi! I have just commited many enhancements to SimpleTaglib. Most noteworthy are: - option for run-time called subs like TaglibHelper - much simpler replacement for childStruct using XML::Smart - option for nestable object-like tags, similar to esql:query - a 'default' tag handler - module is now warning clean And yet, SimpleTaglib is fully backwards compatible (or should be), so please test it and report any problems you encounter. Your old taglibs will generate a few warnings, read the docs on how to modify your code if this annoys you. Apart from that, any SimpleTaglib-based taglib behaving differently than before is a bug in SimpleTaglib. -- 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: [ANNOUNCE] Miscellaneous stuff
Am Sunday, 14. September 2003 21:37, schrieb Tom Schindl: > Hi Jörg, > > in your module Apache::AxKit::Provider::SQL you are calling the function > Apache::AxKit::Provider::register_protocol. This function is not part of > Axkits-Provider.pm that's why I think you've patched it, right? > > Could you maybe provide the patch to me? You can actually remove that call if you do not intend to use sql:// URIs. I am yet unsure what to do with my patch, as I am not yet sure it is ready for general digestion. -- CU Joerg - 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 19:10, Jonas Oberg wrote: > Jörg Walter <[EMAIL PROTECTED]> writes: > > This is not actually a IE issue, but specified in the HTML standard. > > Image submit buttons submit the coordinates where the click occurred. > > So IE is then more standards compliant than Mozilla (which submits > both the button and the coordinates)? In either case, it now works > flawlessly, as does most of AxKit. Okay, reading the standard again, it seems that IE's behaviour mimics NN4's behaviour, while Mozilla follows the specs, although they are a bit diffuse. -- 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 . 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]
[ANNOUNCE] Miscellaneous stuff
Hi! I have finally taken time to set up a CVS server for my own stuff. On http://cvs.garni.ch you will find a Web-CVS interface and anon-cvs instructions. cvs.garni.ch contains all my CPAN modules, some are not yet released, some are more recent than what's in CPAN (people having problems with Apache::AxKit::Plugin::Session, for example, should look at it). cvs.garni.ch also contains various useful stuff that was not yet packaged as a CPAN module. The module PerlPlaypen contains among other things the often mentioned SQL provider and other modules useful in conjunction with AxKit. A true diamond for all IRC users is the BotPluggable module, which contains a big plugin pack aimed at providing Bot services in the same league as eggdrops, perlbot or dancers. It is not released yet, as the aim is to be a 100% replacement (feature-wise) for perlbot, but it is working and already very usable. Developers/contributors wanted! Please bear with the bad doc situation in some modules - if you have questions, mail me. -- 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: 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: Caching and AxKit
Am Tuesday, 09. September 2003 00:14, schrieb Arne Claassen: > From what i can tell (which is without benefit of docs, since i can't > seem to find any on caching and AxKit), caching works only for the > finalized document, correct? There's no caching of stylesheets, so that > it doesn't have to be loaded for every page that requires it (assuming > the resulting page is not cached). XSLT style sheets are cached in memory after first use. So after a while, all your apache processes should have preparsed stylesheets readily available, independent of cache settings. You usually do not need more, as libxslt is really fast at parsing XSLT stylesheets. -- CU Joerg - 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]
