Re: Slow response time
[EMAIL PROTECTED] wrote: Lo all, I have a page that is generated from data in a db. The users are complaining that it takes from 30s to 60s to load the page. Now I have put logging into apache and from the start of the request to the end (of my code) takes about 14s. Which means the bottleneck is either in AxKit or a net one. How can I log the start and finish time of the AxKit pipeline? I have come up with turning the trace on and looking at the timestamps on the intermediate files, but that isn't ideal. I'd rather it went to the apache log. There is only the one transform the xml goes through. I would say that the most likely culprits would be either your XSL stylesheet processing taking up an inordinate amount of time or a slow net connection. Slow stylesheets could be due to a number of factors, such as issuing lots of document() calls which may be waiting on external resources, downloading of remote DTDs, or even simply just a big source XML or XSL stylesheet to process. If you want more details about AxKit's processing, you can set or increase your AxDebugLevel (see the AxKit manpage for more information on this) to gain visibility into what AxKit is doing when it's processing your request. This data will be sent to your error_log. Good luck. -- Michael A Nachbaur <[EMAIL PROTECTED]> http://nachbaur.com/pgpkey.asc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ANNOUNCE: Introducing Apache::AxKit::Language::SpellCheck 0.01
Hey everyone, I've had a bad day, and decided to whip up something interesting and totally unnecessary in my day job, but nonetheless fun to build. So, I thought it would be appropriate to combine Text::Aspell with AxKit. Thus has Apache::AxKit::Language::SpellCheck version 0.01 come into being. This language module doesn't actually use a stylesheet, but rather consumes an XML DOM object (either from a Content provider, or from a previous language pipeline stage) and spell checks its text() nodes. If there are any spelling errors, it will replace the offending word with an XML snippet similar to the following: http://nachbaur.com/2004/07/17-spell-check#";> CASS CUSS CSS The namespace URI is *definitely* going to change, as soon as we can settle on one. In fact, I was going to point it at axkit.org, but forgot to change it over. If anyone has suggestions, shout 'em out. The uploaded file Apache-AxKit-Language-SpellCheck-0.01.tar.gz has entered CPAN as file: $CPAN/authors/id/N/NA/NACHBAUR/Apache-AxKit-Language-SpellCheck-0.01.tar.gz size: 2961 bytes md5: c58d93d4b8aafc21ba4a9ec68a1f3867 -- Michael A. Nachbaur <[EMAIL PROTECTED]> http://nachbaur.com/pgpkey.asc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: multiple select with AxKit::XSP::Param
[EMAIL PROTECTED] wrote: Any ideas on how to get multiple select data (where a user selects more than one value) from AxKit::XSP::Param or is it even possible? $cgi-param(q| foo |); will return only the first element when called in scalar context, but I don't know how to get my taglibhelper-based taglib to call it in array context. Any ideas? You might want to look into AxKit::XSP::QueryParam. Its a bit more verbose than A::X::Param, but it allows you to do more with query parameters. In particular, you might want to look at and . They allow you to, respectively, get a query parameter with a supplied index number, and get the number of parameters with a given name. -- Michael A. Nachbaur <[EMAIL PROTECTED]> http://nachbaur.com/pgpkey.asc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Which Linux for a newbie?
Randall Marbach wrote: Hi ALL I am new to linux and AxKit but I want to set up a simple linux based Axkit server for learning purposes. I would like to choose a linux distribution that has a tried and true track record with perl, apache, modperl and AxKit. What which linux distro would satisfy my requirement? Would I have to install perl from source? At the risk of starting a holy war, all I can do is recommend what I use. I know other developers here use Debian, Gentoo and so forth. I personally use Mandrake (on both my desktops and my servers). Their apache/mod_perl/perl installs are current enough, and built friendly enough, that I don't have to build anything from scratch to get it working with AxKit. If you do a Mandrake install, make sure you install libxslt1-devel and all its dependancies (it should automatically detect the dependancies for you). Or, once your OS is running, you can type "urpmi libxslt1-devel" as root, and it'll install what it needs. Beyond that, installing AxKit is pretty straight forward. -- Michael A. Nachbaur <[EMAIL PROTECTED]> http://nachbaur.com/pgpkey.asc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AxKit and Voice XML?
Nathan Schroeder wrote: At the risk of sounding like a record-skipping fanboy, SAWA would make a great framework for creating providers in. If you don't like the complexity of such a framework, then plain providers would still be quite an improvement. Wow, seems like a lot of anti-taglib sentiment out there... :) I think I agree, but I honestly haven't ever messed with providers in AxKit -- the main project I'm using AxKit for was already well underway when I inherited it, and pretty entrenched with the taglib scheme. In coming up to speed on AxKit I was intrigued by providers and the simplicity / power they seemed to offer, but I never had a chance to build anything with them. Well, I don't think its anti-taglib sentiment as much as it is pro-provider cheering. Taglibs definitely have their place, and IMHO can be a much more powerful mechanism for developing web applications than conventional PHP or ASP code can. However, Providers are just so much more powerful than Taglibs that I shudder at the thought that I might one day have to go back to using PHP. I feel that XSP+Taglibs allow you to leap into building a web application faster than providers, especially if you don't quite grok AxKit in the first place. But, in my experience, using providers lets you go much farther with your web application without bitrot seeping in. -- Michael A. Nachbaur <[EMAIL PROTECTED]> http://nachbaur.com/pgpkey.asc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AxKit and Voice XML?
Robin Berjon wrote: Nathan Schroeder wrote: Anyone out there using AxKit with a VXML gateway or anything? We're looking at some options for an IVR solution, and it seems like we might be able to quickly write some taglibs for VXML output and be halfway there. Or even if no one's doing it, anyone have any input on the idea? Seems like a natural partnership for the technologies... It does seem like a natural partnership, though I don't think of anyone who's done it yet. I'd be interested in hearing about how it went if you do it that way. Also, you mention taglibs but depending on what you're trying to do there may be better options (eg providers). The AxKit book has a discussion of the pros and cons IIRC, though people here might chime in with their views. *chime* At the risk of sounding like a record-skipping fanboy, SAWA would make a great framework for creating providers in. If you don't like the complexity of such a framework, then plain providers would still be quite an improvement. The idea of using AxKit and VXML has been bandied about but neither I nor the people I've spoken with have had the time to do anything substantive with it. Please keep us informed of your exploits with this, because I think this is something we'd all have an interest in, if only for the "Oh, cool!" factor. -- Michael A. Nachbaur <[EMAIL PROTECTED]> http://nachbaur.com/pgpkey.asc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RFC] Need A Name: Yet Another Shopping Cart
Christopher H. Laco wrote: That is the east part. :-) The hard part is coming up with a name/namepsace. Since it's main focus is AxKit, I figured I'd try here first for ideas. Well, I know Kjetil Kjernsmo and Nik Clayton use the AxKit::App namespace for their applications. I'm working on one at the moment that is also within that same namespace, though I might change it as the Package::Names::Are::Getting::Way::Too::Long. If its simple, then AxKit::App::SimpleCart or something of that sort may work for you. -- Michael A. Nachbaur <[EMAIL PROTECTED]> http://nachbaur.com/pgpkey.asc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is the list down?
On November 22, 2004 11:09 am, Christopher H. Laco wrote: > Is it just me, or is the email list down? > I haven't gotten anything all weekend. I don't believe so. For my part, my lack of mailing list chatter was due in part to my trying to have a life this weekend. I failed, but that's life, isn't it? :-) -- Michael A. Nachbaur <[EMAIL PROTECTED]> http://nachbaur.com/pgpkey.asc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ANN: AxKit::XSP::BasicSession 0.20
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On September 17, 2004 10:13 am, Kjetil Kjernsmo wrote: > I haven't really got a complete overview of the codebase, so questions > should probably be addressed in this forum. And, I'm not going anywhere. I just felt that, since very little of what I do these days has anything to do with XSP, I wasn't doing the module any justice just letting it collect dust. > Thanks to Mike for everything he has done so far, and to Mark for > contributing the BasicAuth code. And thanks to you Kjetil for picking this module up. If anyone wants AxKit::XSP::QueryParam ... *wink*wink* - -- Michael A. Nachbaur <[EMAIL PROTECTED]> http://nachbaur.com/pgpkey.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBSyr7vow0fXaFDZQRAjZPAJsHGsq7nD3csmIvcfQjo+nCH9v7FwCfSbe6 pU0BczMzvaYMjhzQ7g8BnOc= =Ynl1 -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Calling an XSP from a stylesheet doesn't get session information
I apologize for the _astoundingly_ late reply. We already talked about this in IRC, so I'll just reply for the benefit of mailing list archives. Kjetil Kjernsmo wrote: I have an XSP that generates a menu, and the idea is to include this menu on every page by calling it within a document() in the transformation to XHTML. When loading an XSP page's results from a browser, the cookie is dumped onto the user's browser. When loading an XSP page from within an XSLT document() function call, the server itself is the client for that HTTP transaction, so any cookies that have been set in the browser will not be seen by the server. But since I'm using a completely new http request, I really don't understand why the session information isn't available to the menu.xsp... Any suggestions...? I ran into this exact same situation myself, and so I've created an extension to AxKit::XSP::BasicSession that allows you to specify a URI query argument to load the session-ID from. PerlSetVar BasicSessionURIToken SID Therefore, any sub-requests you load can be supplied with the session ID on the URI in the document() function. Thanks to the patch you made (which I hope to release today) you'll be able to get the session ID from an AddXSLParams varible. Cheers! -- Michael A. Nachbaur <[EMAIL PROTECTED]> http://nachbaur.com/pgpkey.asc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DOCTYPE
On September 5, 2004 12:38 pm, Freeloader Groups wrote: > Hi All, > IÂm tying to clean up my HTML, first step add the proper DOCTYPE > declaration! > > Problem is I canÂt see to get AxKit to output the proper directive. I > currently have an xml:output within my top level style sheet that looks > something like; > > doctype-public="-//W3C//DTD XHTML 1.0 Transitional//EN" > doctype-system="http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"/> I have the following in one of my stylesheets: http://www.w3.org/TR/html4/strict.dtd"/> And it outputs the DOCTYPE properly in its output: http://www.w3.org/TR/html4/strict.dtd";> The important thing, however, is this is the last stylesheet in the pipeline. That may be what your problem is. Other than that, it should work. -- Michael A. Nachbaur <[EMAIL PROTECTED]> http://nachbaur.com/pgpkey.asc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tips on using session information in AxKit and outside of AxKit
On August 11, 2004 03:53 am, David J Craigon wrote:
> Using Apache::AxKit::Plugin::BasicSession. This is great, except I
> haven't been able so far to access the data outside of AxKit.
I haven't tried it myself, but instead of using
Apache::AxKit::Plugin::BasicSession as an AxKit plugin, you can try setting
it up in one of the mod_perl handler phases, just as long as it happens
before the content phase. This would cause it to fire on all requests, not
just AxKit requests, and would set up the session object in the pnotes table.
Then, you should be able to use the methods provided in
AxKit::XSP::BasicSession (e.g.
AxKit::XSP::BasicSession::get_attribute("foo")). I have a version of that
module somewhere (I just checked CPAN, and it doesn't seem to be there) that
allows you to construct a BasicSession object, enabling you to use it outside
of AxKit.
Another possibility is to simply create your own Apache::Session handler, and
store the session in $r->pnotes() (just look at the existing Plugin code to
see how this is done). However, done this way, you wouldn't get all the
nifty options that the BasicSession plugin gives you (like last_modified
time, etc).
--
Michael A. Nachbaur <[EMAIL PROTECTED]>
http://nachbaur.com/pgpkey.asc
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: custom handler for xml content?
On August 10, 2004 08:38 pm, Mark Hedges wrote: > Hi, xpathscript is awesome but I think XSP/ESQL is a little > clunky for what I want to do on the content side Yes, XSP/ESQL can get you started quickly, but in the long-haul it tends to get you bogged down. I know, I maintain two separate projects that consist of *LOTS* of XSP and ESQL, and it is not a fun place to be. > I would really like to supplant the XML content file with a > reference to my own custom perl handler module, so I can > interface directly with my object models, do some more > complicated perl, and return my own XML output to be marked up > by the xpathscript file. Generating XML dynamically from your own handlers is a great way to go. I highly recommend http://www.oreilly.com/catalog/xmlaxkit/index.html for learning more about AxKit. It has a great chapter on generating Dynamic XML, and talks about the different methods for doing it. As you'll see if you get the book, it shows how easy it is. > Is this possible? It would be a lot easier. I have tried > things like proxying through an 'xml' location, or trying > 'AddHandler' but those don't work. At the risk of sounding rude, I think a well-intended RTFM will go a long way here. The AxKit man page mentions the AxContentProvider option, which is discussed in more detail in Apache::AxKit::Provider. Though, I must say that the book mentioned above does a much better job. > There isn't really any reference I can find on ESQL, either. > How would I do a recursive query to follow a chain of database > entries and build XML nodes on the fly? The example in the AxKit::XSP::ESQL manpage should get you started. You'll want to keep an eye out for the "ancestor" attribute on the tags. Regarding ESQL reference, I'm not sure of anything other than the ESQL manpage, and http://nachbaur.com/software/writing/Fun_with_ESQL.xhtml. I wrote that article quite a while ago, and I haven't touched it since, it still shows some practical examples of ESQL code, for what its worth. -- Michael A. Nachbaur <[EMAIL PROTECTED]> http://nachbaur.com/pgpkey.asc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Caching Foreign Feeds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On August 1, 2004 05:37 am, Kjetil Kjernsmo wrote: > http://slashdot.org/slashdot.rdf > HTTP/1.1 200 OK > Connection: close > Date: Sun, 01 Aug 2004 12:33:16 GMT > Accept-Ranges: bytes > ETag: "1ae259-7b5-410cde4f" > Server: Apache/1.3.29 (Unix) mod_gzip/1.3.26.1a mod_perl/1.29 > Content-Length: 1973 > Content-Type: text/xml > Last-Modified: Sun, 01 Aug 2004 12:13:03 GMT > Client-Date: Sun, 01 Aug 2004 12:34:15 GMT > Client-Peer: 66.35.250.150:80 > Client-Response-Num: 1 > X-Bender: An upgrade? I thought we all agreed I was perfect. > X-Powered-By: Slash 2.003000 > > (uhm, what's Bender doing there, and what is he trying to tell > us...? :-) ) > > Is /. brain-damaged, or is the brain-damage in my end? Its just a custom header that spits out random Futurama quotes. If you HEAD slashdot multiple times, it'll give X-Fry, X-Bender, X-Leela, etc. Quite funny, if somewhat pointless. - -- Michael A. Nachbaur <[EMAIL PROTECTED]> http://nachbaur.com/pgpkey.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBD902vow0fXaFDZQRAs8pAJ9KUeZujNquSWMZttvXfy2qXcJDwwCfaH0U jmm+ZFhOtxpVVJUsKVNzIc4= =owGK -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Provider->get_strref()
Tom Schindl wrote: I've written a custom file provider which uses Text::VimColor to transform code portion in the XML file into XML markup. Everything is working perfectly but while developing I came learned that the get_strref and get_fh methods are called on every request. Although the XML and XSL-Files have not changed and everything is delivered from cache. I'm afraid that on a heavy loaded site I'm running into performance problem. Could someone explain to my why this is done, isn't it enough to simply look onto the timestamps of the files used? Well, this probably won't solve your problem, but you may want to take a look at: http://search.cpan.org/~nachbaur/Apache-AxKit-Provider-File-Syntax-0.05/ :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Announce: O'Reilly's XML Publishing with AxKit
On July 21, 2004 09:48 am, Robin Berjon wrote: > Kip Hampton wrote: > > _XML Publishing with AxKit_ has been published and is now available at > > bookseller near you! For more information, please see the Table of > > Contents below and visit: > > > > http://www.axkitbook.com/ > > I've read that book, and I have to say it's probably one of the finest > to come from O'Reilly (and no, I don't get royalties for saying this ;). > I've known AxKit very well for years, yet that book still managed to add > some coherence to that knowledge -- I'm sure reading it will be > beneficial to any AxKit user (and likely, to any Cocoon user). I'd have to agree with this. Using the section on producing dynamic XML is what helped push me over the edge from XSP to building my own custom providers. Kip's been harping on me for some time that Providers are a way easier development paridigm, but I just hadn't grok'd the concept until I read his book. Way to go Kip! -- Michael A. Nachbaur <[EMAIL PROTECTED]> http://nachbaur.com/pgpkey.asc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_rewrite wants to serve me application/x-xsp
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On July 16, 2004 10:39 am, Kjetil Kjernsmo wrote: > When I go to http://localhost/news/submit it correctly finds submit.xsp, > but the problem is that it doesn't hand the XSP to > Apache::AxKit::Language::XSP like it should, it serves me the page as > application/x-xsp directly... > > I've tried different variations of this theme, like moving things > around, so that the rule is before or after the AxAddStyleMap, adding > [T=application/x-xsp], and now finally, I tried simply adding an Alias, > not using mod_rewrite at all. All with the same results. Hmm, how are you telling Apache to use AxKit for your xsp files? Do you have something like: or the like? - -- Michael A. Nachbaur <[EMAIL PROTECTED]> http://nachbaur.com/pgpkey.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA+BhJvow0fXaFDZQRAgPDAJ9hIM9yeHvoDgngKc5vo+OKFGMs2wCfcCvB nt6gVHps1V6eiq6WmK/9iws= =MpwJ -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ANN: Apache::AxKit::Provider::File::Syntax
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On July 16, 2004 01:22 am, Matt Sergeant wrote: > On 14 Jul 2004, at 13:36, Michael A Nachbaur wrote: > > This has been kicking around in my personal CVS repository for a > > little over 4 > > months, and I just finally got around to checking it into CPAN. It > > uses the > > Text::VimColor module to generate XML content based on the syntax of a > > source > > file. For an example of how this looks (when applied to a stylesheet) > > take a > > look at: > > > > http://aom.nachbaur.com/syntax/examples/operating-systems.rdf > > http://aom.nachbaur.com/syntax/examples/menulist-1.xul > > http://aom.nachbaur.com/syntax/examples/menulist-1.js > > > > While the first two files are XML on disk, you'll notice that the > > third is a > > JavaScript file. Good luck, and let me know if you have any feedback. > > Now *that* is cool. Do I smell the start of an AxKit front end to some > sort of revision control system? Well, I'm not a big fan of viewcvs.cgi, but I don't have the time (or inclination) to replace it. Mainly this is just a way for me to prettify the code samples on my Mozilla Application Object Model reference. Though it does allow AxKit do some really wild things. :-) I'm thinking something along the lines of an intelligent error.xsl that can show you a snippet of the offending source XML might be neat. - -- Michael A. Nachbaur <[EMAIL PROTECTED]> http://nachbaur.com/pgpkey.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA+AN0vow0fXaFDZQRAlY0AJ95boI06YGr1vBu0BfHQ6ZHutOCwACfVPWe jhnd5wxloKDREyvmIeE4xzw= =kPt1 -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ANN: Apache::AxKit::Provider::File::Syntax
Hello AxKittens. Here's another CPAN module for those of you out there who are interested. The uploaded file Apache-AxKit-Provider-File-Syntax-0.02.tar.gz has entered CPAN as file: $CPAN/authors/id/N/NA/NACHBAUR/Apache-AxKit-Provider-File-Syntax-0.02.tar.gz size: 2511 bytes md5: 2cec26de6258d21cd8e7d9b3d229fdf0 This has been kicking around in my personal CVS repository for a little over 4 months, and I just finally got around to checking it into CPAN. It uses the Text::VimColor module to generate XML content based on the syntax of a source file. For an example of how this looks (when applied to a stylesheet) take a look at: http://aom.nachbaur.com/syntax/examples/operating-systems.rdf http://aom.nachbaur.com/syntax/examples/menulist-1.xul http://aom.nachbaur.com/syntax/examples/menulist-1.js While the first two files are XML on disk, you'll notice that the third is a JavaScript file. Good luck, and let me know if you have any feedback. -- Michael A. Nachbaur <[EMAIL PROTECTED]> http://nachbaur.com/pgpkey.asc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PassiveTex & FOP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On July 8, 2004 01:54 pm, John Russell wrote: > Is there a reason for the choice of PassiveTex over FOP for > rendering FO in AxKit? I wondered this myself, but after I had a hard time getting PassiveTex to do what I wanted, the reason became less important than "how do I get my document to render properly?" Consequently, I blatantly ripped off the PassiveTex Apache module and made AxKit::Language::Language::FOP. If anyone else would like it, I could release it as a CPAN module. For the time being however, you can get it at http://cvs.nachbaur.com/cgi-bin/viewcvs.cgi/Apache-AxKit-Language-FOP/ - -- Michael A. Nachbaur <[EMAIL PROTECTED]> http://nachbaur.com/pgpkey.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA7sImvow0fXaFDZQRAl/vAJ9z2Tiw3XkDTlVBui0FZOE3TJ7yxACfZ/K2 uamE0UDB3VOF/om9EFaMMQY= =QnDj -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XSLT-accessed query params and testing existance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On July 8, 2004 09:01 am, Kjetil Kjernsmo wrote: > On torsdag 8. juli 2004, 16:59, Michael A Nachbaur wrote: > > > Is that line really necessary? > > > > Not really. It mainly can be used to supply a default, non-empty, > > value. So, if you say: > > > > > > > > and then later say > > > > http://www.exslt.org) you could probably use the eval() function to create an XPath expression and evaluate it, to perform your test. At this point however, I think it might be worth taking a step back and trying to determine what you're getting done, and perhaps refactor what you're doing, instead of trying to force the XSL params functionality into place. Perl-space would be a good spot to look for that. - -- Michael A. Nachbaur <[EMAIL PROTECTED]> http://nachbaur.com/pgpkey.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA7YaPvow0fXaFDZQRAtcUAJwO+pAokXjPC6nHg0Q0W+bsYeFoDQCcCKTh KL/gj0LZ0KzRTDRg9hDfCKw= =zfth -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XSLT-accessed query params and testing existance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On July 8, 2004 03:53 am, Kjetil Kjernsmo wrote: > On onsdag 7. juli 2004, 18:41, Michael A Nachbaur wrote: > > > But then, I need to test whether a parameter exists... In XSP > > > that's straightforward, thanks to the many good taglibs, but I > > > haven't found anything on checking the parameters in XSLT, is it > > > doable? > > > > Well, the most common method I know of doing that is: > > > > > > Is that line really necessary? Not really. It mainly can be used to supply a default, non-empty, value. So, if you say: and then later say http://nachbaur.com/pgpkey.asc > > Uhm, you didn't get the new key right, but I'll take that in a private > e-mail. :-) Blast it! *sigh* :-) - -- Michael A. Nachbaur <[EMAIL PROTECTED]> http://nachbaur.com/pgpkey.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA7WFfQy51zN2518IRAomrAKDtizeBq2YLGJO74e0nEh3zjnFIkgCgi2OU w8ysDYB5j5lILQRlSrNvquE= =dVcR -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XSLT-accessed query params and testing existance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On July 7, 2004 07:56 am, Kjetil Kjernsmo wrote: > But this is of little use, because I'd like to have a single template > replacing all the possible parameters, so instead of $title, I should > use the > @name > (i.e. the name attribute of the val:insert element), to identify the > parameter. That's a pure XSLT/XQuery question I guess, but I might as > well ask: Any ideas on how to do that? > > But then, I need to test whether a parameter exists... In XSP that's > straightforward, thanks to the many good taglibs, but I haven't found > anything on checking the parameters in XSLT, is it doable? Well, the most common method I know of doing that is: You can probably clean this up a bit by using named templates. > Is there more documentation on the parameters AxKit pass to XSLT > somewhere now? I remembered an old thread about them and found it in > the archives, but that was about all. IIRC, by default it adds the query string parameters supplied to the URL, and any additional parameters added by any AxKit plugins that are supplied. For instance, you can use one of the Apache::AxKit::Plugin::AddXSLParams::* modules to put in additional parameters as needed. Kip wrote a module to parse out the HTTP Request object and supply detailed parameters for them (::Request) and I have a module that can take values stored in your BasicSession and supply them to your stylesheet. > Kip, anything about that in your new book? It's in the mail on its way > here... :-) Good choice! Its a really great book. I've been an AxKit regular for a while now, and I've learned quite a few things in there. - -- Michael A. Nachbaur <[EMAIL PROTECTED]> http://nachbaur.com/pgpkey.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA7Ce5Qy51zN2518IRAuYsAJ0fcK4uz+EXyyNTdFgdVNv+HaGLWACdFmIJ hEVAbuiWrcH45dqYRHa/ng4= =QWDn -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ANN: AxKit::XSP::BasicSession 0.18
This is just a minor, stupid bugfix release. If you've upgraded to 0.17 and found that, surprise, it doesn't work anymore, try 0.18 out. It was just uploaded to CPAN, so it may take a few hours for it to be mirrored. -- Michael A. Nachbaur <[EMAIL PROTECTED]> http://nachbaur.com/pgpkey.asc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Content Management for AxKit/Apache
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On July 1, 2004 09:55 am, Robin Berjon wrote: > Michael A Nachbaur wrote: > > My goal is, when I eventually get back to Callisto, to make any text > > generated from your source XML - whether its the main body content, or > > the titles of other pages listed in a side- or nav-bar - could be edited > > without having to hop around your site. This is because the client could > > submit content updates to various target URLs asyncronously, as long as > > it knew what URL / XML ID a given DOM node in the browser was associated > > with. > > Just a drive-by comment: it really sounds like you want XForms :) I haven't investigated XForms much, but it seems...err...complicated. What I really want is to be able to transparently edit server-side XML content (keeping the semantic structure of the XML itself) while interacting with the result of an XSL transformation. Things could be potentially simplified by performing the XSL transform within Mozilla, but then there wouldn't be a guarentee that the content would render the same in AxKit. :-\ - -- Michael A. Nachbaur <[EMAIL PROTECTED]> http://nachbaur.com/pgpkey.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA5EPLGQXhotBzUNcRAm4BAKDM0WOWhEyYcLM8O2d5iZ3t2WXOFQCfRdeU Ygo4CVZDsH8+zBuRqmtVLVM= =2LFz -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Content Management for AxKit/Apache
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On July 1, 2004 08:11 am, Michael Kröll wrote: > Tom Howe wrote: > | this could be integrated into something like XIMS to offer this XML > | style content creation? > > Joachim Kargl, here at the Univ.Innsbruck is currently involved in a > project that includes integrating the web-based XML Editor BitFlux > (http://bitfluxeditor.org/) into XIMS. That is scheduled to be finished > by September, in theory it sounds really good. > > What also sounds interesting would be something like a Mozile based XUL > editor (e.g. http://www.playsophy.com/edom/demos/XML/xuleditor.xul), but > ~ that's not yet on our short-term TODO list. I have, in my development area, a proof-of-concept merging the features of Mozile with Callisto, e.g. the result of your site's XSLT transformation can be edited in-situ. It shows a lot of promise, in that the client can become an active party to the editing process, rather than the server throwing gobs of HTML forms to the browser, and recieving gobs of updates in batch. Instead, the browser could send small packets of updates to the server, either as RDF (since Mozilla's RDF APIs rock) or as XML or HTTP POST updates. > Michael Nachbaur, author of CallistoCMS, did a lot of work with XUL > based interfaces, maybe he can give an update there? So far my XUL work has focused around client/server administration GUIs, since my projects at work have drifted away from Callisto for the time being. :-( I do have plans to get back to Callisto, but I don't have any time in the forseeable future to get to it. My goal is, when I eventually get back to Callisto, to make any text generated from your source XML - whether its the main body content, or the titles of other pages listed in a side- or nav-bar - could be edited without having to hop around your site. This is because the client could submit content updates to various target URLs asyncronously, as long as it knew what URL / XML ID a given DOM node in the browser was associated with. - -- Michael A. Nachbaur <[EMAIL PROTECTED]> http://nachbaur.com/pgpkey.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA5EDqGQXhotBzUNcRAnlVAJ9YT/hkRgUdsGBFvuFXodK5sX+suQCfe1Mt R+fvCHiybKrv3w9YZYf1QTQ= =b2AG -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: axkit survives a slashdotting
S.Woodside wrote: Hi my site http://semacode.org just got slashdotted but survived just fine. The load average is at 1.00, caching is on, it's all XSLT (no XSP though) serving up the weblog feed on the main page and everything. No problemo. Congratulations! Can you give a bit more information about the hardware and the pipeline layout? I've performed benchmark tests with "ab" numerous times on my AxKit websites, but there's nothing that can equal a Slashdotting for testing the true merit of your application's performance. -- Michael A. Nachbaur <[EMAIL PROTECTED]> http://nachbaur.com/pgpkey.asc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Outage
On May 5, 2004 12:24 pm, Matt Sergeant wrote: > We just had a minor outage of the axkit.org server due to what seems > like a corrupt disk partition. This seems to have recovered itself > after an fsck, however I'm a little nervous about how fragile it might > be now, so will be purchasing a new disk probably tomorrow, and try and > build a new server, so you might want to expect some more outage in the > near future, but hopefully I will be able to give advanced notice next > time. Well, my company has offered to provide hosting for axkit.org for free. You have your choice of putting it on the company's server, or mine (dual xeon, 2.5GB ram, RAID-0 SCSI). If you want, I can set you up with a shell account and you can move the site over before you do your server maintenance. -- Michael A. Nachbaur <[EMAIL PROTECTED]> http://nachbaur.com/pgpkey.asc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ESQL Woes
On April 23, 2004 09:48 am, Tim Hibbard wrote: > I'm having a problem debugging an ESQL app. I am a newbie to AxKit and > found this particulary hard to decode. Any help is very much apprecitaed. > I look forward to getting my brain injected with XML. Yes, debugging programatically-generated Perl code resulting from an XSP file can be a chore. > Here is my xsp page: > > xmlns:xsp="http://www.apache.org/1999/XSP/Core"; > xmlns:esql="http://apache.org/xsp/SQL/v2"; > > > > Oracle > host=xxx.xxx.xxx.xxx;sid=LEO;port=1521 > valid-user > valid-password > > > select * from LEO_DATA.INFOED_PROPOSAL > > > > > > > > > > > > My first reaction to this is that you don't have a parent tag around your . When the XSP code is run, it will generate XML to be outputted to the next stage in the pipeline, and if your SQL statement returns more than one row, there will be multiple sibling XML nodes in the output. Since an XML parser will bark at you if you try to add more than one root node, it would thrown an exception. Other than that, everything up above looks fine, though I don't have first-hand experience connecting to an Oracle database via ESQL. -- Michael A. Nachbaur <[EMAIL PROTECTED]> http://nachbaur.com/pgpkey.asc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PerForm 1.83
I ran into something similar a while back due to a PerForm update. I cannot remember what the version numbers are, so its possible this isn't your problem, buuuttt... When I updated PerForm, I didn't take the updated XSL stylesheet for rendering the PerForm elements. Some of the code changes relied on changes in the form field names (for instance, __submitted or something like that became __submitted_). So, when you submit, the XSP taglib didn't know what form you were submitting, and subsequently didn't do anything. Try that out and see if it solves anything for you. Colin Goodier wrote: Hi, We recently upgraded to PerForm 1.83 in an attempt to get rid of the bug in the 1.7 version whereby the drop-down menus are not re-populated when the form is re-submitted when there is an error in the original submission. However, we found that the upgrade caused more problems, in that the form appeared not to be submitted at all! So, as the lesser of two evils we reverted to the older version, which at least works. Has anybody else had any problems with the latest version of PerForm? I was wondering if I could get round it by using JavaScript to validate the form, but I see that the 'onSubmit' (or onClick') call is a feature of the later versions only, so may be a no-no for us too :-( Colin Goodier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XSLT design strategy
Kjetil Kjernsmo wrote:
Dear all,
There is an abundance of XSLT resources on the net and in books that
discuss the details of XSLT, but yet, I feel I'm struggling to get
things right...
We've all been there before. XSLT turns conventional procedural
programming on its head, and it can often be difficult to relinquish
control to the XSLT transformation engine, and trust it to just do "The
Right Thing(tm)".
I'm by no means an expert (any experts here?) but I find my method works
well for what I use it for. Keep in mind that I only ever develop sites
in English, so for information on multi-lingual sites, you may want to
dig a bit deeper.
Usually, I design content to be rendered to multiple output types (e.g.
pretty XHTML, printable XHTML, PDF, raw source, etc). I utilize
to merge common functionality, rather than the AxKit
pipeline, except in situations where my source XML needs to be scrubbed
prior to display processing (e.g. to merge multiple XML files, pre-sort
data, etc).
Here is some sample code from the site I'm working on now. I've trimmed
it down for brevity.
AxAddRootProcessor text/xsl /stylesheets/object-xhtml.xsl object
AxAddRootProcessor text/xsl /stylesheets/object-print.xsl object
Here I have two stylesheets that match for the same root element, in
different AxStyleNames. In the "object-xhtml.xsl" file, I have:
http://www.w3.org/1999/XSL/Transform";>
"common.xsl" defines common EXSLT functions, templates, etc.
"object.xsl" processes the actual document data, and finally the
"design-xhtml.xsl" stylesheet overrides any other templates for
rendering with the site's pretty XHTML look & feel. The only difference
between this file and "object-print.xsl" is the last import statement
loads "design-print.xsl". This file also gives you the opportunity to
override any templates within your standard "object.xsl" file, so as to
customize how something will look within a given output style.
Each of the design-*.xsl stylesheets outputs XHTML that includes either
design-xhtml.css or design-print.css for the page's cascading
stylesheets. Each of them includes as the first line:
@import url("common.css");
so I can have common site styles, with each AxStyleName possessing it's
own custom style rules for each output type.
Finally, I define a style name for outputting the source XML verbatim,
with the exception of a little scrubbing:
AxAddProcessor text/xsl /stylesheets/raw.xsl
this way, if I need to, I can do an if I need to merge data from
other data sources. For instance, I have a glossary.xml file that
defines words so, within any document, I can wrap a given piece of text
with to, if present in the glossary.xml file,
create a tool-tip definition for that word. (Note: There's probably a
better way of handling this; anyone?)
If you want to see this in action check out http://aom.nachbaur.com/
(its in CVS at
http://cvs.nachbaur.com/cgi-bin/viewcvs.cgi/MozillaAOMReference/ if you
want to take a look at how I build the source, but be warned: its still
in active development).
I have data flowing from several different sources: The same document
fragment may come from a Provider, or from some XSP. Also, my basic
idea is that many things should be included by XSLT. For example, I
have had the idea that stuff that are common for for the entire site,
such as headers, menus and the like, should be imported by an XSLT by
for example an axkit: URI. Also, since my own language is spoken by
only 4 millon people, I'm going multi-lingual from the start, and I
figured I want a separate page with phrases, so that languages can be
added by simply have someone translate a single file.
How you architect your stylesheets really depends on how the data is
structured, how the page will be structured, etc. For instance, I find
the above design pattern works well for the sorts of sites I build, but
there are instances where I use the AxKit pipeline instead to output to
plain-and-ugly XHTML, and then further style it with additional stylesheets.
So, how do you folks designing this stuff, and do you know some good
resources that deals with things like this rather than the details?
I too would be interested to see how other people design their sites.
There's always something you can learn from someone else's design
patterns. My method more-or-less congealed, and I'm sure there are some
sticking points that I've run across that could be mitigated if I just
found out another way to do it.
Perhaps the [EMAIL PROTECTED] would be a better place to
discuss this, but I feel that people here are always so nice and
helpful, and besides, it is in connection with AxKit that I'm
wondering.
I'm sorry I haven't replied earlier than this, but between work and the
aforementioned site, I've been stuck on my little hamster-wheel. :-)
Cheers!
-
To unsubscribe, e-
Re: Need a wiki janitor [x-adr]
On Wednesday 11 February 2004 01:00 pm, Robert Ferney wrote: > One of the solutions is to implement a simple rollback so that the users > can revert to the pre-graffiti version easily. This would include IP > tracking for the changes, so the reversion would back up, or atleast > have the possibility of backing up prior to all the changes made by that > IP address. > It is not nearly as attractive to the graffiti kiddies if their spam can > be easily removed. > > Another possibility would be to have accounts as a method of signing the > changes. This does have the controversial effect of excluding anyone who > does not wish to make an account, or those that would prefer to remain > anonymous. This has both pros and cons. One further suggestion would be to allow changes to be made from anonymous users, but require that those changes be ratified by a validated user. So, even if some spam kiddie were to deface a wiki page, it would require a person with a user account to say "Yup, allow these changes to go through". -- /* Michael A. Nachbaur <[EMAIL PROTECTED]> * http://nachbaur.com/pgpkey.asc */ "One's never alone with a rubber duck. " - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Need a wiki janitor
On Tuesday 10 February 2004 03:20 pm, Matt Sergeant wrote: > I'm currently facing a bit of a constant battle with wiki abusers - > either porn peddlers trying to add links (see the history for the Links > page), or just people randomly clearing page content and clicking > submit. This is getting rather tedious and time consuming. > > Would anyone be willing to volunteer to watch the axkit-dev list and > revert to an earlier version of a page when someone breaks a wiki page? > All the diffs are mailed to the axkit-dev list, so it becomes really > easy to spot. I'm just now trying to recover the QuickStart that was recently wiped, and the wiki seems to be ill. It submits to /edit/, and after a protracted pause, gives me the feared 404 error. Any ideas? -- /* Michael A. Nachbaur <[EMAIL PROTECTED]> * http://nachbaur.com/pgpkey.asc */ "Another world, another day, another dawn. " - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Need a wiki janitor
On Tuesday 10 February 2004 03:20 pm, Matt Sergeant wrote: > I'm currently facing a bit of a constant battle with wiki abusers - > either porn peddlers trying to add links (see the history for the Links > page), or just people randomly clearing page content and clicking > submit. This is getting rather tedious and time consuming. > > Would anyone be willing to volunteer to watch the axkit-dev list and > revert to an earlier version of a page when someone breaks a wiki page? > All the diffs are mailed to the axkit-dev list, so it becomes really > easy to spot. I can help out with this (and have frequently gone to correct a wiki update only to find that you'd already fixed it), but I can't guarantee that I'll get to it right away. Perhaps we can have several people who will monitor / update the wiki as bad changes are put in? -- /* Michael A. Nachbaur <[EMAIL PROTECTED]> * http://nachbaur.com/pgpkey.asc */ "A thought seemed to strike the woman. It struck her very slowly. You could watch it coming in like a long wave on a sandy beach." - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ANN: AxKit::XSP::BasicSession 0.17 released
The uploaded file AxKit-XSP-BasicSession-0.17.tar.gz has entered CPAN as file: $CPAN/authors/id/N/NA/NACHBAUR/AxKit-XSP-BasicSession-0.17.tar.gz size: 9436 bytes md5: e45eba3b717155670b941369d488ef46 This release of BasicSession is primarily a feature release. It adds the same if/unless logic tags available in QueryParam, but for querying Session keys. I plan another update soon to overhaul the BasicAuth code, but that will have to wait until next week. For now, here is the relevant entry from the change log. Changes: - Added control logic (if/unless, etc) - Added more documentation and comments - Fixed an annoying bug that makes session names "_" -- /* Michael A. Nachbaur <[EMAIL PROTECTED]> * http://nachbaur.com/pgpkey.asc */ "You're very sure of your facts, " he said at last, "I couldn't trust the thinking of a man who takes the Universe - if there is one - for granted. " - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PerForn design question
On Sunday 01 February 2004 01:15 pm, Adam C. Migus wrote: > All, > I've been playing with PerForm and have a design issue that I haven't > been able to find much about in the archives. > > My particular application of PerForm at this point is an account request > form though I think generally speaking this query can apply to a fairly > broad set of forms related design. > > In my current revision I request the pertinent information, do the > necessary checks via validation and commit on submit however I'd like to > design my forms in a "wizard like" fashion. I have actually just completed a wizard-like PerForm interface allowing users to create and edit their email accounts. It gives them a step-by-step interface for entering in information, and manages the "Next', "Back" and "Cancel" submit actions for traversing various pages. Trans-Page state is maintained in an AxKit::XSP::BasicSession datastore, and even information about what the next page will be is stored in a session key. This works out quite well. If you want more information, I can send you the XSP I use for the interface. The key thing about it's structure is it has a wrapper around multiple blocks, and the XSL stylesheet, based on the "CurrentPage" session key, displays and processes only one form block at a time. -- /* Michael A. Nachbaur <[EMAIL PROTECTED]> * http://nachbaur.com/pgpkey.asc */ "Does it worry you that you don't talk any kind of sense? " - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ANN: AxKit::XSP::QueryParam uploaded to CPAN
The uploaded file AxKit-XSP-QueryParam-0.02.tar.gz has entered CPAN as file: $CPAN/authors/id/N/NA/NACHBAUR/AxKit-XSP-QueryParam-0.02.tar.gz size: 3480 bytes md5: 7e5020f4b8291fb2d1a8bcd9e06d3842 This is a minor feature release, mainly to accomodate the recent suggestions / requests from Kjetil Kjernsmo. In case you didn't follow that thread, here's the entry from the Changes file: - Added - Made understand indexes - Made optionally limit it's output to just one parameter name -- /* Michael A. Nachbaur <[EMAIL PROTECTED]> * http://nachbaur.com/pgpkey.asc */ "There was a point to this story, but it has temporarily escaped the chronicler's mind." - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple equal-named parameters in XSP
On Tuesday 27 January 2004 02:30 am, Kjetil Kjernsmo wrote: > But it doesn't do all I wanted, at least not straightforwardly. I want them > all! :-) That is, a list of all parameters for a name. With the two > additions, I guess you could do that with a loop, but then, I have this > something against mixing in Perl... In the interest of backwards > compatability and maintaining relative simplicity, I guess it is best to > keep that element like it is... :-) Hmm...okay. So, you wanna take perl completely out of the picture. > May I suggest an element, something like > > that if given the query ?foo=bar&foo=baz > will return > bar > baz So I gather you're going to be post-processing this? > Possibly, the name of the element (instead of 'value') could be an > attribute too, and perhaps an optional element around these... Actually, I added an optional "name" attribute to "enumerate", so you could say: > > =head2 C<> > > > > Returns the number of parameters provided on the request. If a name is > > provided, the number of parameters supplied for the given name is > > returned. If the name is left out, then the total number of parameters is > > returned. > > Hm, this returned 1 on me if I used multiple parameters with the same name. > With different parameters, and no name attribute, it was correct. I'll try > to look more about what could be the matter with that later (gotta run now > (quite literally)). Okay, this should be fixed. The latest version is in CVS. Try it, test it, and let me know how it worked out. > > This code is *completely* untested, since my development server has been > > taken by my SysAdmin for some emergency server replacement work, > > Uhm, that's life... :-) I don't even have a separate development server (so > I do most work on my workstation, and upload when I want others to have a > look). One of the nice things about using AxKit as a central part of your company's business is that you get good servers to develop on. One of the downsides of the same, is that now everyone relies on it, which means you can no longer do ad-hoc code changes, or you'll *instantly* hear everyone groan "SCAMP's down!" *sigh* You know, it occurs to me that this would be well-suited to the axkit-devel mailing list. Oh well. -- /* Michael A. Nachbaur <[EMAIL PROTECTED]> * http://nachbaur.com/pgpkey.asc */ "Anyone who is capable of getting themselves made President should on no account be allowed to do the job." -- Some wisdom from The Book. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple equal-named parameters in XSP
On Monday 26 January 2004 02:29 pm, Kjetil Kjernsmo wrote: > Mike's new QueryParam has an enumerate element that I suppose could list > all the elements, and it fooled me for a moment (ha, I bet you did that on > purpose, Mike! ;-) ), but I think it would be overkill for my purpose. I > want just a list of these parameters, not all the others... Great idea! I never thought about that before. After a few moments of happy hacking, I've pieced together two changes to A:X:QueryParam: =head2 C<> Get a value from the given parameter. The "name" attribute can be passed as a child element for programattic access to parameter values. If the index attribute is supplied, and if multiple parameters are supplied for the same "name", then the appropriate parameter is returned. If multiple values for the same parameter are given, but no index is supplied, the first value is returned. Now, if you can understand that convoluted set of instructions, then you're smarter than me! =head2 C<> Returns the number of parameters provided on the request. If a name is provided, the number of parameters supplied for the given name is returned. If the name is left out, then the total number of parameters is returned. This code is *completely* untested, since my development server has been taken by my SysAdmin for some emergency server replacement work, so if anyone wants to grab the latest copy out of CVS and try it out, go for it. If you do try it out, let me know if it works / fails, so I can release it to CPAN or fix the bugs, respectively: http://cvs.nachbaur.com/cgi-bin/viewcvs.cgi/*checkout*/AxKit-XSP-QueryParam/lib/AxKit/XSP/QueryParam.pm?rev=1.2 -- /* Michael A. Nachbaur <[EMAIL PROTECTED]> * http://nachbaur.com/pgpkey.asc */ `This must be Thursday,' said Arthur to himself, sinking low over his beer, `I never could get the hang of Thursdays.' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XSP page inheritance
On Monday 19 January 2004 12:43 pm, Matt Sergeant wrote: > On 19 Jan 2004, at 19:44, Michael A Nachbaur wrote: > > On Wednesday 14 January 2004 12:02 pm, Matt Sergeant wrote: > >> On 14 Jan 2004, at 17:20, Nathan Schroeder wrote: > >>> ...but I keep getting "Can't locate object method "cache_params" via > >>> package . . . " errors when I hit the page. The page itself is > >>> equally simple, and works fine if I take out the base-class line in > >>> xsp:page. > >> > >> Ah yes - this is fixed in CVS, sorry. > > > > Hmm, apparently it isn't, because I just checked out from CVS (on > > apache.org) > > and got the same thing. I checked the AxKit module on cvs.axkit.org, > > but > > that seems to be pretty old. > > Very odd indeed. What is the Id number of your XSP.pm file? I chatting with medwards on #axkit-dahut, I've discovered that I somehow got a version from August 2003...odd, that. I'm currently in the process of rectifying that. Okay, I just checked out / installed, and I got XSP.pm: # $Id: XSP.pm,v 1.52 2003/10/31 17:04:46 jwalt Exp $ The line number it's complaining about has changed (196), but it's still this line: my $xsp_cache = Apache::AxKit::Cache->new($r, $package, $package->cache_params($r, $cgi)); -- /* Michael A. Nachbaur <[EMAIL PROTECTED]> * http://nachbaur.com/pgpkey.asc */ `I am so amazingly cool you could keep a side of meat in me for a month. I am so hip I have difficulty seeing over my pelvis.' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XSP page inheritance
On Wednesday 14 January 2004 12:02 pm, Matt Sergeant wrote: > On 14 Jan 2004, at 17:20, Nathan Schroeder wrote: > > ...but I keep getting "Can't locate object method "cache_params" via > > package . . . " errors when I hit the page. The page itself is > > equally simple, and works fine if I take out the base-class line in > > xsp:page. > > Ah yes - this is fixed in CVS, sorry. Hmm, apparently it isn't, because I just checked out from CVS (on apache.org) and got the same thing. I checked the AxKit module on cvs.axkit.org, but that seems to be pretty old. Any word on this? -- /* Michael A. Nachbaur <[EMAIL PROTECTED]> * http://nachbaur.com/pgpkey.asc */ "`If there's anything more important than my ego around, I want it caught and shot now.'" -- Zaphod. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another session library
On Tuesday 06 January 2004 08:29 am, Martin Oldfield wrote:
> In part this was because I found both A::X::Session and
> A::X::BasicSession hard to either make work or understand, but also
> because I wanted a library I could use from both Perl and XSP (the
> latter being a thin SimpleTaglib layer thrown round the former).
I don't have the time to do your code justice (I'll look at it this evening)
but I just wanted to toss in my $0.02 CAD for what it's worth (which is about
$0.0155 USD).
A::X::BasicSession can actually be used from both XSP and Perl.
A::X::Plugin::BasicSession creates and manages the actual session object
itself, and dumps the tied session in the pnotes() table. A::X::BasicSession
is simply a convenient wrapper around the pnotes() tied object, and uses
TaglibHelper to expose that to XSP.
So, for instance, I do the following all the time:
foreach my $field (keys %{$ctxt->{Form}}) {
next if ($field =~ /__/);
next if ($field =~ /\./);
next if ($field eq 'apply');
if ($field eq 'preference-search_results_pagesize') {
AxKit::XSP::BasicSession::remove_attribute('search-max');
AxKit::XSP::BasicSession::remove_attribute('search-skip');
}
AxKit::XSP::BasicSession::set_attribute($field, $ctxt->{Form}->{$field});
}
Now, there may be an easier way to access that, for instance by making a
constructor. So, you could do:
my $obj = new AxKit::XSP::BasicSession;
$obj->remove_attribute("foo");
Would anyone find that useful? I don't mean to suggest that one person's
implementation is better than another, but I'd like to prevent any further
confusion with sessions in AxKit. Two (or three?) session taglibs is already
pretty confusing as it is.
Either that, or I'd find having a "Best Of Breed" approach useful, deprecating
an older taglib in favor of an easier to install and use taglib that takes
pieces of different taglibs and has a fresh new lemon scent. ;-)
--
/* Michael A. Nachbaur <[EMAIL PROTECTED]>
* http://nachbaur.com/pgpkey.asc
*/
"Rome wasn't burned in a day. "
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Announce] CallistoCMS 1.0 released
After an interminable duration of time, during which Callisto development languished, I've finally bitten the bullet and released 1.0 of Callisto. I was tired of sticking around with release candidates that were, for all intents and purposes, official releases, so I decided to call a spade a spade and release 1.0. This release fixes a few show-stopper bugs that were fixed in CVS, improves the installation process significantly, and adds FTP-only deployment (which in itself simplifies installation). There are still many changes yet to come in the deployment area, but those are primarily in the realm of intelligent-agent deployment across a parallel server farm. If you only need to deploy to a single server with FTP, what is in there now should suffice perfectly. Other notable changes to this release is the addition of image support in documents. You can insert an image just like you would a paragraph or a list. There are some neat properties of this feature, most notably being the automatic thumbnail preview when choosing an image. This is another area that will be seeing some improvements over the next few weeks, with the addition of file-browsing for inserting images and links and uploading of files (images, PDFs, etc) coming soon. Though this is a 1.0, I have plenty planned and I hope to follow the Open Source philosophy of "Release Early, Release Often". If you'd like to try the online demo of Callisto, go to http://www.callistocms.com/demo.xml and try both the Editing and Production views, to see how the same site is presented in both environments. You can download the latest version of Callisto at http://sourceforge.net/projects/callistocms -- /* Michael A. Nachbaur <[EMAIL PROTECTED]> * http://nachbaur.com/pgpkey.asc */ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Development re-started on Callisto
If anyone wants to add features, please let me know and I'll stay in touch (or join the callistocms-users or -devel mailing list). -- /* Michael A. Nachbaur <[EMAIL PROTECTED]> * http://nachbaur.com/pgpkey.asc */ "Anyone who is capable of getting themselves made President should on no account be allowed to do the job." - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Phat/Rich Clients, AxKit, and the Web's Future
John Edstrom wrote: Case in point: XUL has been around for years (both in development and release), yet it is not widely adopted as a platform for software development. I think this has largely to do with the fact that Mozilla for teh past few years has been such a bloody slow beast that no one wanted to write applications for it. I myself had a hard time, until Firebird became stable. Now it's a joy to write for, even though the learning curve is pretty steep. I don't have any first hand experience with XUL, but I'm skeptical. I've noticed that with mozilla and even firebird, it seems every minor browser version breaks one or more skins. Some of the old skins can crash the new browser. At least from my perspective as a user it looks pretty brittle and fragile. This, AFAIK, is due to changes in the underlying XUL. XUL describes the layout of the application, and the CSS describes what it will look like. CSS is usually bound to elements in the XUL code based on ID, and if changes in the underlying XUL occur, then the CSS must change as well. Mozilla and Firebird are extremely complicated applications, and while the skinning functionality is a very flexible feature, it is as much a part of the application development process as the XUL+JavaScript itself. If you were developing an XSP web app, your XSL stylesheet would be an integral part of that application, and a fundamental change in one would require a change in the other. That is what's going on here. So, this skinning method may seem brittle to end users, but gives the developers a very extensible development environment. I see what you mean though. I for one wish the Orbit theme worked on the latest nightly build. Oh well, you can't have everything. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Phat/Rich Clients, AxKit, and the Web's Future
S Woodside wrote: On Wednesday, November 19, 2003, at 07:22 PM, Michael A Nachbaur wrote: So, anyway, to answer the question, I would like to see better support for outputting RDF in AxKit. Perhaps I had better spit the RDF out as a result of an XSL transform, but somehow that never occurred to me before. Right .. I was just going to say, what makes RDF so special that you can't use the normal XMLish tools to generate it? The main issues I was fighting with was my inexperience with RDF, and the self-referential nature of RDF. It would have been much easier to use a taglib, or some XSL transformer to take my already nicely heirarchial structure and format it appropriately in RDF. *shrug* /me thinks some RDF research is in order - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Phat/Rich Clients, AxKit, and the Web's Future
Robin Berjon wrote: Michael A Nachbaur wrote: On Wednesday 19 November 2003 12:47 am, Robin Berjon wrote: Do you have specific technical ideas that we should work on to facilitate this? In my (short) experience building Mozilla+XUL applications, the thing I noticed the need for most was RDF input. I'm confused :) You say RDF input here, but then later all you talk about is RDF output. Or is it RDF output from AxKit that's input to Mozilla? AxKit -> RDF -> Mozilla It is true that RDF input (to AxKit) is hard, because of the flexibility of RDF's expression in XML. The same statement can be said in many ways, and that requires a specialised RDF parser. We don't currently have that in AxKit, and it would be really nice to have it available as aProvider (possible one providing a canonical view of RDF so that it'd fit better into the whole pipeline, which easier XSLT processing and so on). If your problem is outputting RDF/XML from AxKit, then it really shouldn't be that hard (as you note later). Honestly, if you're talking about 4000 statements, that doesn't seem like much at all. True, with XSLT you have to output it all at once, but it's *really* fast, and the IO may actually be simpler (ie faster). If your current stuff is slow, you should give LibXSLT a try, it still surprises me sometimes :) Yeah, I'm using LibXSLT, but I was still seeing some pretty odd delays. The main issue was not in the actual load time, the three seconds it was taking being quite acceptable. It was the percieved load delay, since several RDF data sources were being loaded simultaneously and delaying the rendering of the "Intro" screen, so to speak. This is really just an implementation detail, but the thing that chafed on me was the tedious nature of outputting RDF with it's heirarchial ID tags, and so forth. This application was a "Wowzer!" prototype application, the sort you show to your boss to try and dazzle him with bullsh*t so he'll give you the budget to write the application you want (and make it OSS in the end). The percieved load time was a big thing that won me the project, even though in production it probably wouldn't be done that way anyway. So, anyway, to answer the question, I would like to see better support for outputting RDF in AxKit. Perhaps I had better spit the RDF out as a result of an XSL transform, but somehow that never occurred to me before. If you have specific needs going from an RDF model to its XML expression, then AxKit is lacking, but if it's just generating XML then you should have all the tools :) If the former, you might want to look at http://search.cpan.org/~zooleika/RDF-Simple-0.04/ which is a nice package despite the fact that it uses TT2. :-) I would actually like to round-trip RDF. I have three main paths I could take for building my app: a) have a Mozilla interface act as a web-service client, b) have the interface just scrape values from raw XML outputted from AxKit, or c) round-trip RDF to-and-from Mozilla, feeding RDF to the client interface that describes form values, and then taking the resulting RDF and updating the necessary database values as they're changed. I still don't know what the "Best" way of doing this would be, as several fires have broken out and I've had to resort to my more baser abilities (http://nachbaur.com/software/reproxy/), but I would like to investigate the possibility of either an RDF scrubber like you describe above, or a Web Service provider of some sort. Right now, the only way I can forsee really leveraging AxKit's abilities for interacting with the Mozilla client is to do option (b), scraping raw XML, which isn't actually that difficult, AFAICT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Phat/Rich Clients, AxKit, and the Web's Future
This thread is getting quite sociable. :-) On Friday 21 November 2003 12:58 pm, Adam Turoff wrote: > The "phat" clients you describe are something of a holy grail for > technologists. Technically, they're better solutions than rewriting > everything in Java, relying on Qt or Wx for cross-platform products, > working within the contraints of [X]HTML/HTTP, porting to C# (and hoping > Rotor/Mono work out if you need cross-platform support) or cracking open > that copy of Petzold's Win32 programming that's sitting under your monitor. > > These are the kind of toolkits toolsmiths want to write, but do they > provide the kind of environment workaday hackers want to use? So far, > the answer is a resounding "no". I believe the answer to this question is left up to the developers themselves. Like the saying "If you build it, they will come", if a killer tool is available, people will use it if it (a) meets the needs of the moment, (b) is easier to do than the equivilant task using current tools, or (c) the resulting application would be otherwise impossible or impractical to implement any other way. I for one am implementing two applications in Mozilla XUL at the moment; an intranet application that is already a successful, and horribly slow, web app, and a refactored interface to my CMS that already functions through standard HTML. The reason for this is simple; stock HTML just doesn't cut it for me. I could probably limit myself to one browser and leverage all the fancy JavaScript capabilities it provides, but this assumes those capabilities are standard across all versions and platforms of that application. I'm dropping support for IE and Konqueror, simply because I cannot support the differences in JavaScript and DOM implementations across three browsers. If I'm going to focus on one browser (Mozilla, since there is a requirement that the applications are accessible from both Windows and Mac, and I develop under Linux) I might as well take advantage of all it has to offer, and use all the bells and whistles that it provides me. That means XUL, and that means the burdon of developing menus, toolbars, treeview and the like are now handled by native widgets and I can get on with the job of making the thing work. > The reason why webapps made it big is because they solved many of the > nasty problems of client-server software created, and solved those > problems by breaking all the rules. There's a *huge* class of > applications that shouldn't be done with fat clients, and the web solves > that problem 9 times out of 10 -- with CGI, PHP, J2EE or mod_perl and > AxKit. This is true, but to follow the C adage "C makes easy things hard, and hard things possible." Writing XUL apps is not meant to be the norm for web application developers, just as writing a simple home page for your grandmother's cookie recipe need not be written in AxKit/XSLT. The fact that the XUL and phat client developer community isn't as large as the HTML/PHP/CGI community is comparing apples to oranges. I think a closer analogy would be to match the XUL community with intranet Oracle Reports applications, or SAP and all it's ilk. > Case in point: XUL has been around for years (both in development and > release), yet it is not widely adopted as a platform for software > development. I think this has largely to do with the fact that Mozilla for teh past few years has been such a bloody slow beast that no one wanted to write applications for it. I myself had a hard time, until Firebird became stable. Now it's a joy to write for, even though the learning curve is pretty steep. > (I'm waiting for someone to create a desktop app called AmazonShopper > or something that de-clutters the shopping experience at Amazon. Or > not, depending on what their license permits.) Check out http://mab.mozdev.org. It's a Mozilla app for searching / browsing Amazon's product catalog. ;-) -- /* Michael A. Nachbaur <[EMAIL PROTECTED]> * http://nachbaur.com/pgpkey.asc */ Trin Tragula - for that was his name - was a dreamer, a thinker, speculative philosopher or, as his wife would have it, an idiot. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Phat/Rich Clients, AxKit, and the Web's Future
On Friday 21 November 2003 09:10 am, Tod Harter wrote: > Well, I wasn't even THAT sophisticated... I simply created my page just > like I usually do and at the point where content normally lives, a I > just identified that td with id='x'. Somewhere in my page is a wad of > javascript placed there by an XSLT template match to some tag in my > original source XML. That javascript finds the , uses XMLHttpRequest() > to request whatever component is supposed to go there, optionally gets an > XSLT transform and applies it, and attaches the result to the DOM tree at > the specified location. In addition to HTML this can also contain the > javascript for event handlers etc. > > The only reason for even going through javascript is just that my concept > was to build fairly large chunks of GUI and include them as needed. The > nice thing in that case is that your DATA can be already in the page and > remain local while you do whatever you want with the user interface. The > same basic kinds of techniques can be used with smaller widgets though, and > of course the XSLT can happen on either server or client, as is convenient. > Something like XUL could be generated just as easily as HTML, and the > syntax for specifying the components in the first place could be quite > varied as well, XForms, etc. Odd, I've been doing web development for eons now, and I've never even thought of doing that. I try to stay away from the client-side rendering capabilities of browsers since I have an urge to stay Lynx-compatible. :-) I was working on CallistoCMS (http://callistocms.com) and was running into the problem of having server-side XML, needing to render it as HTML/Forms with XSLT, but not wanting to reload from the server with every update. (the website is currently partially broken, unfortunately) This technique would really improve things for my interface, and seeing as I've been planning on making this 100% Mozilla-based, so I can use advanced widgets like tree-views and so forth, so I wouldn't have to worry about cross-browser incompatibilities. > I built a little site map editor this way. In my case I built a javascript > class that could load the sitemap, display it, save it, etc. Its nice > because you can save the sitemap and still keep editing it without it > needing to be reloaded as with conventional forms based systems, plus my > editor is far nicer than any form The complete package consists of the > data, a javascript .js file that defines the class, and an XSLT transform > that turns the data into the HTML interface and 'glue' javascript to > propagate events to my class. The whole thing is still fairly clunky, but I > can send you some files. Currently it only works in Mozilla, but I could > make it work in IE in theory. I'd love to see your samples, if you can provide them. I have been working on a prototype XUL application, which queries RDF sources, so if you want to share code, I can send some files your way as well. -- /* Michael A. Nachbaur <[EMAIL PROTECTED]> * http://nachbaur.com/pgpkey.asc */ "You're very sure of your facts, " he said at last, "I couldn't trust the thinking of a man who takes the Universe - if there is one - for granted. " - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Phat/Rich Clients, AxKit, and the Web's Future
On Thursday 20 November 2003 07:43 am, Tod Harter wrote: > On Wednesday 19 November 2003 7:22 pm, Michael A Nachbaur wrote: > > So, anyway, to answer the question, I would like to see better support > > for outputting RDF in AxKit. Perhaps I had better spit the RDF out as a > > result of an XSL transform, but somehow that never occurred to me before. > > Interesting. I am trying a different tack. My client-side application is > built by loading an initial page, which contains javascript logic which > goes back to the server via XMLHttpRequest(), gets whatever data is > required for the particular operation being performed (served back as raw > XML by the server side), applies XSLT to it, and attaches the resulting UI > to the DOM tree in whatever is designated as the content area for whatever > enclosing UI element is holding this 'panel' or whatnot. XUL could > certainly be incorporated in there, but basically what I have is a > component and a corresponding XSLT to instantiate it. You can go back and > forth to the server all day and there are no 'pages' being loaded. In fact > the application becomes entirely a normal event-driven GUI, albeit with > some javascript glue logic. Intriguing. Do you perhaps have any samples you would be able to show that illustrates this concept? Does the client-side application provide the "Controller" part of the framework? What is the result of the XSLT transform, a conventional web page rendered in a element, or plugged straight into a standard container element like a or element? -- /* Michael A. Nachbaur <[EMAIL PROTECTED]> * http://nachbaur.com/pgpkey.asc */ Trin Tragula - for that was his name - was a dreamer, a thinker, speculative philosopher or, as his wife would have it, an idiot. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Phat/Rich Clients, AxKit, and the Web's Future
Michael Kröll wrote: Michael A Nachbaur wrote: | So, anyway, to answer the question, I would like to see better support for | outputting RDF in AxKit. Perhaps I had better spit the RDF out as a result | of an XSL transform, but somehow that never occurred to me before. Why is that? Even if it is not the nicest thing to look at, it does work perfectly well. (Depending on the libxml+XML::LibXML combination you are using, of course) I guess the response to that could be either (both?) of a) I didn't think of it at the time, and b) I was outputting 4000+ RDF entries in a single file (building a Mozilla tree widget) and I wanted Mozilla to load it while it was downloading, rather than waiting for the entire thing to be built first. I originally had it written as an AxKit XSP, but the percieved load time was awful. The eventual load time was just as bad with a mod_perl handler, but no one notices... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Phat/Rich Clients, AxKit, and the Web's Future
On Wednesday 19 November 2003 12:47 am, Robin Berjon wrote: > Do you have specific technical ideas that we should work on to > facilitate this? In my (short) experience building Mozilla+XUL applications, the thing I noticed the need for most was RDF input. I've been developing a really sweet intranet application for a little over a year. It's built in AxKit and is full of sexy graphs and little buttons and icons, and is very neat. But, it is also horrifically slow due to the sheer number of forms and elements that must be processed on every screen refresh. I've started transitioning my application to use a Mozilla XUL client application, installed using a download from the intranet website, that presents the user with a fat client interface to the same server-side intranet application. Mozilla has made a really big commitment to RDF for all manner of aspects of it's basic operations; tree views, templated XUL sections (for repeatable clusters of display elements), menus and so on can all be programmatically built using RDF as a datasource. The bummer about all this is I find it pretty hard to generate RDF using AxKit. I ended up dropping down into a plain'ol mod_perl handler, and printed out the RDF tags manually. My XUL application is still just a prototype, but I'd like to see this functionality merged into AxKit more before going whole-hog into it. So, anyway, to answer the question, I would like to see better support for outputting RDF in AxKit. Perhaps I had better spit the RDF out as a result of an XSL transform, but somehow that never occurred to me before. -- /* Michael A. Nachbaur <[EMAIL PROTECTED]> * http://nachbaur.com/pgpkey.asc */ "Anyone who is capable of getting themselves made President should on no account be allowed to do the job." - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCE] AxKit::XSP::QueryParam 0.01
The uploaded file
AxKit-XSP-QueryParam-0.01.tar.gz
has entered CPAN as
file: $CPAN/authors/id/N/NA/NACHBAUR/AxKit-XSP-QueryParam-0.01.tar.gz
size: 2979 bytes
md5: 00124ab6358621880e4d989902628791
===
I love writing quick snippets in XSP, but find evaluation logic to be a pain
in the butt. For instance:
if ( =~ /joe/) {
}
The taglib is great, but is IMHO pretty limited. Therefore,
QueryParam is supposed to be a rather verbose replacement for it. It allows
you to set, get, remove, enumerate through, and do if / unless matches
(including regular expression matches) on URI arguments.
I actually wrote this a long time ago, but totally forgot to wrap it up into a
CPAN module. So, here it is!
Questions, comments, threats, bribes, are all welcome.
--
/* Michael A. Nachbaur <[EMAIL PROTECTED]>
* http://nachbaur.com/pgpkey.asc
*/
...[Arthur] leapt to his feet like an author hearing the phone ring...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCE] AxKit::XSP::BasicSession 0.16
The uploaded file AxKit-XSP-BasicSession-0.16.tar.gz has entered CPAN as file: $CPAN/authors/id/N/NA/NACHBAUR/AxKit-XSP-BasicSession-0.16.tar.gz size: 10096 bytes md5: 244c25d7d05f8fd019a0530dfb082d79 === BasicSession is an AxKit taglib / plugin that provides simple session support to AxKit XSP pages. Thanks to a contribution by Mark Hershberger, it now has basic Authentication support as well. My QA server is currently on blocks, so I can't test to make sure everything works, but it should (/me knocks on wood). -- /* Michael A. Nachbaur <[EMAIL PROTECTED]> * http://nachbaur.com/pgpkey.asc */ "Zaphod grinned two manic grins, sauntered over to the bar and bought most of it." - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AxKit sessions
I use (and wrote) AxKit::XSP::BasicSession which is just a plain-vanilla interface to Apache::Session. It's IMHO easy to install and to use, but doesn't offer much in the way of bells & whistles; if you want integrated authorization / authentication, support for URI- or cookie-based session tokens, etc, then try getting AxKit::XSP::Session working instead. Jörg Walter's Apache::XSP::Session module is IMHO way better than my AxKit::XSP::BasicSession, but is a little difficult to get installed and configured. -- /* Michael A. Nachbaur <[EMAIL PROTECTED]> * http://nachbaur.com/pgpkey.asc */ On Monday 08 September 2003 10:51 am, Vaclav Barta wrote: > Hi, > > I've been evaluating AxKit for a toy web app, and found surprisingly little > about session management. There's Apache::AxKit::Plugin::Session, but its > Wiki page (http://axkit.org/wiki/view/AxKit/ApacheAxKitPluginSession) > states that "if using v0.93, I you'll need to patch Session.pm and Auth.pm" > according to some CPAN URL which doesn't make a lot of sense > to me... I can confirm that version 0.93 (which is what's in CPAN) indeed > does not install cleanly; I could try to debug it, but isn't there > something that works out of the box? Doesn't anybody use persistent state > with AxKit-generated pages? > > Bye > Vasek > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Building applications with AxKit and XSP, in a reusable extensible way...
On Wednesday 23 July 2003 05:04 am, Adam Griffiths wrote: > > Pg > dbname=axkit > postgres > password > > > > One suggestion to make your ESQL code less redundant is to put your connection information in environment variables. For instance, here's a (slightly altered to protect the innocent) snippet from my httpd.conf: PerlSetEnv PGDATABASE "dbname" PerlSetEnv PGHOST "hostname" PerlSetEnv PGUSER "username" PerlSetEnv PGPASSWORD "[EMAIL PROTECTED]" PerlSetEnv DBI_DSN "dbi:Pg:dbname=dbname;host=hostname" Now all I have to do to make calls to my database is to do something like the following: -- /* Michael A. Nachbaur <[EMAIL PROTECTED]> * http://nachbaur.com/pgpkey.asc */ "He expanded his chest to make it totally clear that here was the sort of man you only dared to cross if you had a team of Sherpas with you. " - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Deferring XSL transformation to the browser
Hello all, Another thought/question. Many versions of modern browsers support client-side XSL transformation, but as we all know no two XSL engines are created equal (especially when dealing with bloody IE ... but I digress). Anyway, I know that with the HTTP compression Apache modules that it has a list of browsers that incorrectly advertise gzip support. Is there a module / code snippet that'll allow me to determine if the client has "real" support for client-side XSLT, allowing me to just spit out XML? If not, I feel an itch that I might have to go and scratch. -- /* Michael A. Nachbaur <[EMAIL PROTECTED]> * http://nachbaur.com/pgpkey.asc */ "The dew," he observed, "has clearly fallen with a particularly sickening thud this morning." - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Inline-XSP and Taglibs
I'm asking this here because, since I've been out of touch with AxKit's internals for far too many months, I don't have enough data to answer my own question. Basically, I would like to embed XSP code inline in XHTML files. So, I for instance would only like regions of a file to be processed by XSP, and have it's SAX events injected into the XHTML event stream. For instance: boo print 2 + 5 The main reason is that I don't want all XHTML files to be processed through the XSP engine (which, last time I checked, was significantly slower than plain-file-output). The above also could translate to taglibs. For instance: ... ... The key benefits I could see are: (a) The entire page is not cached in memory as a perl handler, (b) in my example, very little of the page would be dynamic code, (c) (far-fetched) identical snippets of code from different pages could just be cached as one handler in memory. I'm refactoring my content management system, and I'd really rather not have the overhead of XSP in every single page if I want just one or two pages in an entire site to have a dynamic snippet. -- /* Michael A. Nachbaur <[EMAIL PROTECTED]> * http://nachbaur.com/pgpkey.asc */ "Another world, another day, another dawn. " - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
PerForm and drop-down boxes
I don't mean to sound like a whining newbie, but I'm about to throw this chunk of code away in a few weeks anyway, so I'm not willing to do much in the way of debugging. I have a PerForm/ESQL interface (that's being rewritten into an object-oriented interface, with a PerForm front-end) that has a select box, a few text boxes, that sort of thing. When I bring the form up the first time, the select box shows the correct default value, as well as all the additional tags. However, if when the form is submitted one of the validation routines dies with an error, the select box is unpopulated when the form comes back up. Is this fixed in 1.8.1? I'm reluctant to upgrade since this web interface is a critical app for my company (has anyone had any major issues with backwards compatibility?) Anyway, thanks a bunch in advance. -- Michael A Nachbaur <[EMAIL PROTECTED]> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: hello!
On Wednesday 28 May 2003 09:05 am, Mauro Sciaccaluga wrote: > On Wednesday 28 May 2003 18:00, Michael A Nachbaur wrote: > > > > Well, it depends on where your data comes from, how much you have, etc. > > If you are using a GUI XML editor or a content editing system that > > exports XML, you may be restricted to the dialect of XML the GUI > > produces. It may include a DTD for the XML for it's own internal > > validation checks. In that instance, since the document already conforms > > to the DTD there's no harm in using that to associate documents with a > > stylesheet. > > > > In other instances you may have a large amount of data, and you don't > > want to change hundreds or thousands of XML files every time the name of > > a stylesheet changes. In either case (and many others) it may be simpler > > to create these document -> stylesheet associations in your httpd.conf > > (or .htaccess file) and just let the XML content creators worry about > > content, and the display creators can worry about the content display. > > > > Yes its what i want to do!! but it seems not to work!! Have you read all my > messages? I have added the directive to process all the documents with my > guide.xsl but it doesnt work. please help me :-) Could you perhaps send the Apache directives you're using so we can help debug your problem? You might also want to turn AxKit debugging on; maybe the error messages could lead you in the right direction. -- Michael A Nachbaur <[EMAIL PROTECTED]> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: hello!
Well, it depends on where your data comes from, how much you have, etc. If you are using a GUI XML editor or a content editing system that exports XML, you may be restricted to the dialect of XML the GUI produces. It may include a DTD for the XML for it's own internal validation checks. In that instance, since the document already conforms to the DTD there's no harm in using that to associate documents with a stylesheet. In other instances you may have a large amount of data, and you don't want to change hundreds or thousands of XML files every time the name of a stylesheet changes. In either case (and many others) it may be simpler to create these document -> stylesheet associations in your httpd.conf (or .htaccess file) and just let the XML content creators worry about content, and the display creators can worry about the content display. On Tuesday 27 May 2003 04:36 pm, S Woodside wrote: > Really? When would you suggest using this feature? > > Simon > > On Tuesday, May 27, 2003, at 06:37 PM, Michael A Nachbaur wrote: > > Well, if your document has a DTD reference in it, you can use that to > > associate your XML documents with the appropriate stylesheet by using > > the > > AxAdd*Processor directives. Look at the AxKit manual page for more > > information. Suffice to say, using your sample configuration, you > > could do: > > > > PerlModule AxKit > > AddHandler axkit .xml > > AxAddStyleMap text/xsl Apache::AxKit::Language::LibXSLT > > AxAddDTDProcessor text/xsl /guide.xsl /guide.dtd > > > > This tells AxKit to use the "guide.xsl" stylesheet (with the text/xsl > > stylesheet processor) whenever the DTD "/guide.dtd" is used in an XML > > file. > > > > Hope this helps. > > > > On Tuesday 27 May 2003 02:19 pm, Mauro Sciaccaluga wrote: > >> Hello everybody, > >> > >> I am a new user to axkit. I like it!! It works great!!! I need just > >> your > >> assistance for a thing i cannot handle very well. > >> > >> Please let me tell you what it happens. > >> > >> I have some .xml file that I want to parse automatically by apache > >> (thanks > >> to axkit naturally) I succeeded to do this. but I have had to > >> change > >> (to add) a thing in these files to get them work: > >> > >> > >> > >> Before there was just: > >> > >> > >> > >> I have both these files: guide.dtd and guide.xsl > >> > >> If I put the stylesheet tag axkit parse this file correctly. How can > >> I tell > >> axkit to use by default the guide.xsl for my xml with just the > >> !DOCTYPE > >> tag?? > >> > >> These are my apache.conf (httpd.conf): > >> > >> .. > >> .. > >> .. > >> PerlModule AxKit > >> AddHandler axkit .xml > >> #AddHandler axkit .xsp > >> #AddHandler axkit .dkb > >> AxDebugLevel 10 > >> PerlSetVar AxXPSInterpolate 1 > >> AxAddStyleMap text/xsl Apache::AxKit::Language::LibXSLT > >> > >> -- > >> > >> Definitely... I don't know much about .dtd files.. please someone > >> helps > >> me!! > >> > >> :-) thanks a lot!! > >> > >> buh bye > >> > >> > >> --------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > > > > -- > > Michael A Nachbaur <[EMAIL PROTECTED]> > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > -- > anti-spam: do not post this address publicly > www.simonwoodside.com -- 99% Devil, 1% Angel > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Michael A Nachbaur <[EMAIL PROTECTED]> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: hello!
On Tuesday 27 May 2003 04:36 pm, S Woodside wrote: > On Tuesday, May 27, 2003, at 05:19 PM, Mauro Sciaccaluga wrote: > > > > > > Before there was just: > > > > > > > > I have both these files: guide.dtd and guide.xsl > > A !DOCTYPE tag is not normal XML I don't think. It's a hold-over from > SGML I think. As far as defining an XSLT transformation on the file, > it's useless. DTD don't transform documents they just specify and/or > validate them. There are some AxKit directives for apache that will > specify a transformation, that are documented on the man page and in > the docs wiki on axkit.org. However Why not just use the > processor include? It's just as good. Actually, is a valid XML tag. See the W3C XML specification[1]. As far as associating XSL stylesheets with an XML file, there are plenty of ways one could do it. A given stylesheet (or pipeline of stylesheets) could be associated based on the root element name[2], a DTD[3], as well as a bunch of others. I usually associate my documents based on their root element, but TIMTOWTDI. Regarding using the directive, not everyone can change their XML content for page rendering. In some instances where I have to process XML, the data cannot be dictated, either because there are simply too many files (1,000s of them), or the XML files are not created by me, but rather generated by a 3rd party. 1: http://www.w3.org/TR/REC-xml#NT-doctypedecl 2: http://www.axkit.org/wiki/view/AxKit/AxKit#AxAddRootProcessor 3: http://www.axkit.org/wiki/view/AxKit/AxKit#AxAddDTDProcessor -- Michael A Nachbaur <[EMAIL PROTECTED]> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: hello!
Well, if your document has a DTD reference in it, you can use that to associate your XML documents with the appropriate stylesheet by using the AxAdd*Processor directives. Look at the AxKit manual page for more information. Suffice to say, using your sample configuration, you could do: PerlModule AxKit AddHandler axkit .xml AxAddStyleMap text/xsl Apache::AxKit::Language::LibXSLT AxAddDTDProcessor text/xsl /guide.xsl /guide.dtd This tells AxKit to use the "guide.xsl" stylesheet (with the text/xsl stylesheet processor) whenever the DTD "/guide.dtd" is used in an XML file. Hope this helps. On Tuesday 27 May 2003 02:19 pm, Mauro Sciaccaluga wrote: > Hello everybody, > > I am a new user to axkit. I like it!! It works great!!! I need just your > assistance for a thing i cannot handle very well. > > Please let me tell you what it happens. > > I have some .xml file that I want to parse automatically by apache (thanks > to axkit naturally) I succeeded to do this. but I have had to change > (to add) a thing in these files to get them work: > > > > Before there was just: > > > > I have both these files: guide.dtd and guide.xsl > > If I put the stylesheet tag axkit parse this file correctly. How can I tell > axkit to use by default the guide.xsl for my xml with just the !DOCTYPE > tag?? > > These are my apache.conf (httpd.conf): > > .. > .. > .. > PerlModule AxKit > AddHandler axkit .xml > #AddHandler axkit .xsp > #AddHandler axkit .dkb > AxDebugLevel 10 > PerlSetVar AxXPSInterpolate 1 > AxAddStyleMap text/xsl Apache::AxKit::Language::LibXSLT > > -- > > Definitely... I don't know much about .dtd files.. please someone helps > me!! > > :-) thanks a lot!! > > buh bye > > > --------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Michael A Nachbaur <[EMAIL PROTECTED]> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: AxKit::XSP::Graph
Unfortunately, the Real World© has struck yet again. The system administrator here has left for medical reasons, and so I'm having to dust off my old sysadmin hat and take over for him. Since that's a full-time job, my XSP work has essentially halted. Since I already have a semi-useful graphing solution (using Apache::GDGraph), the creation of an XSP-based graphing solution is way low on my priority list. Has anyone else come up with anything useful? On April 2, 2003 03:52 pm, Schuetz, David wrote: > Has any progress been made on this? I'm now at a point where the last part > of my prototype I have to convert from php/jpgraph is the graphing/charting > part. > > > At the very least, for an interim solution, can anyone show me an easy way > to do all the GD::Graph stuff in XSP and then send the binary output > directly to the browser? > > I'm able to do a very simple bar-graph in XSP, but when I get to the final > output stage (like "print $graph->gd->png();"), the data comes through all > verschimmeled (specifically, 0xC2's seem to get added at random in the > stream). > > I've tried modifying my A:X:L:FOP (itself a poorly-modified PassiveTeX), > but I can't figure out how to get the binary data to it. If I try to > finish up my XSP with something like print > $graph->gd->png() (notice the subtle jEdit twitch), then I get errors > about invalid UTF-8 / XML encoding (because, of course, the output of the > XSP is no longer XML but is instead PNG data). > > Is there a way that I can "return" raw PNG data and have an output module > grab it and send it to the browser? Can I do this w/out having to take an > intermediate temp file step (which I'd really rather avoid)? If so, then > why do I even need the extra A:X:L (or whatever) step? (for this interim > solution, I'd ultimately prefer a simple, in-the-XSP method to send the > data back). > > > And, of course, the longer-term solution is what was discussed last month > (XCL or whatever it's called this week :) ). I figure there are three > stages to this: > > * Raw GD::Graph code in XSP, somehow returning image data directly to the > browser > * a GD::Graph taglib abstracting GD::Graph functions in XML, and it does > the returning magic > * a new language that can be serialized to svg or png or whatver > > Michael Nachbaur -- if you've got any work done on this, I'd love a copy > that I can muck about with. > > > Thanks! > > > david. > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: Re: Module stats]
Robin Berjon wrote: I thought you guys would be interested in this. Ok, that's only circa 0.02% of the sites running Apache (and knowscape.com going offline knocked around 120 sites off that list), but hey 769 seems rather good to me. That also doesn't include all the sites running from behind a reverse proxy, like mine do. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Business] Anyone need AxKit Hosting?
AxKittens, I'm sorry for spamming the AxKit community for something like this, but it's honestly not because I'm a money grubbing capitalist that wants to prey off his community. :) I'm a sysadmin at an ISP, and I'm rebuilding my main webserver machine (it's been config-tweaked to death, and is becoming difficult to manage). As a result I'm spec'ing out a new machine to use for web hosting. So far, I'm going to run PHP and ASP/FrontPage (*shudder*) on it. I would like to ask you guys if you think it would be a good idea for me to host AxKit sites as well. I run my own servers to host my personal AxKit sites, and I know of many others here who do the same. So, would I be serving the community (as well as myself :) by providing AxKit hosting, or is there no demand for it? I don't want to waste my time (of which there is very little available) supporting a service that won't be used, but at the same time I'd hate to see AxKit newbies move on to PHP just because there was nowhere they could host it. If you think this isn't appropriate for the list, just mail me directly; I'll accept flames, as long as they're intelligently written. ;) -- -man Michael A Nachbaur The best way to predict the Future is to invent it. PGP Public Key at http://www.nachbaur.com/pgpkey.asc PGP Key fingerprint = 83DC 7C3A 3084 6A21 9A3F 801E D974 AFB4 BFD7 2B6F - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: named stylesheets
Eric Stockbridge wrote: and as long as I am asking, what are the pro's con's of choosing Apache::AxKit::StyleChooser::PathInfo or Apache::AxKit::StyleChooser::QueryString AFAIK many search engines don't index pages that have a query string (with the notable exception of Google). As well, though I've never done this myself, it should be possible to use PathInfo in your stylesheets to create links to alternate styles by using relative links. For example: printable version Printable isn't an actual file, but the browser should just tack that on the end of your URI. If you use the Apache::AxKit::Plugin::AddXSLParams::Request AxKit plugin this then becomes unnecessary, because you can then access your URI parameters through XSL parameters; I personally prefer this method. This is pure opinion on my part, but I feel that the path to your content should not include formatting options. (e.g. /articles/networking/firewalls.xml) Any formatting changes to your URI should IMHO go in query parameters, so as to not alter the path to your content (since, really, the content hasn't changed, you're just displaying it in some different way). This is why I use the QueryString StyleChooser. -- -man Michael A Nachbaur The best way to predict the Future is to invent it. PGP Public Key at http://www.nachbaur.com/pgpkey.asc PGP Key fingerprint = 83DC 7C3A 3084 6A21 9A3F 801E D974 AFB4 BFD7 2B6F - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: named stylesheets
Eric Stockbridge wrote: how can I name stylesheets for use with Apache::AxKit::StyleChooser::PathInfo ? This is a bit of an RTFM question, but I'll answer it anyway. There are essentially two ways you can approach this. If you are using httpd.conf or .htaccess files to associate stylesheets with your XML (using the AxAdd*Processor directives), then the following will apply (taken straight from the AxKit documentation): AxAddProcessor text/xsl /styles/webpage_screen.xsl AxAddProcessor text/xsl /styles/webpage_printable.xsl This example assumes that all your files in a given directory will be processed by the same stylesheet. If you need to selectively associate a particular type of XML file with their own stylesheet, then you can use the other AxAdd*Processor directives. For instance: AxAddRootProcessor text/xsl /styles/webpage_screen.xsl page AxAddRootProcessor text/xsl /styles/book_screen.xsl book AxAddRootProcessor text/xsl /styles/webpage_printable.xsl page AxAddRootProcessor text/xsl /styles/book_printable.xsl book Assuming you have two different types of XML content in your site, one whose root element is , while the other's root element is . This will automagically assign a different XSL stylesheet with your XML depending on the name of that root element. See the documentation for more Apache directives like those above. Now, if you're using PIs in your XML files to associate stylesheets, there is a similar process you must go through. Here is a snippet from an actual XSP page of mine that has three views - the default HTML view, a printable version of the HTML and a "pretty-printed" XML representation (redraws the raw XML color-coded for debugging). title="default"?> type="text/xsl" title="print" alternate="yes"?> type="text/xsl" title="prettyxml" alternate="yes"?> The first stylesheet just associates this XML file with the XSP processor. The next three PIs all have the added "title" attribute. The "default" title (and I'm assuming the absense of the alternate attribute) means this is - you guessed it - the default. The others, since they're defined as alternates, can be accessed by their titles. I find the first method (using .htaccess files) much more flexible, but more cumbersome when you have a bunch of XSP pages that all need custom stylesheets. -- -man Michael A Nachbaur The best way to predict the Future is to invent it. PGP Public Key at http://www.nachbaur.com/pgpkey.asc PGP Key fingerprint = 83DC 7C3A 3084 6A21 9A3F 801E D974 AFB4 BFD7 2B6F - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Draft ESQL article
Hello AxKittens! I've been pretty well immersed in ESQL/XSP for the past few weeks, and have picked up quite a few tricks along the way. I spent a little while the other day jotting these down into an article, and have placed it on the web. It's still very much a work-in-progress, but I thought you would like to see it to comment on. If you have any changes, suggestions or corrections to make, please let me know. I may be stating the obvious in this article, but I think it might help quasi-newbies to get a firm footing. http://nachbaur.com/software/writing/Fun_with_ESQL.xhtml This was written using OpenOffice, so if anyone would like to make changes, I can get you the original file. Cheers! -- -man Michael A Nachbaur The best way to predict the Future is to invent it. PGP Public Key at http://www.nachbaur.com/pgpkey.asc PGP Key fingerprint = 83DC 7C3A 3084 6A21 9A3F 801E D974 AFB4 BFD7 2B6F - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Announce: AxKit::XSP::BasicSession 0.15
The uploaded file AxKit-XSP-BasicSession-0.15.tar.gz has entered CPAN as file: $CPAN/authors/id/N/NA/NACHBAUR/AxKit-XSP-BasicSession-0.15.tar.gz size: 8024 bytes md5: 075b6c552ca042f51b3366c864e6a32a From the Changes file: 0.15 Thu Nov 14 11:03:48 PST 2001 - Fixed cookie handling when dealing with multiple cookies bearing the same name 0.14 Wed Nov 13 13:58:52 PST 2001 - Added cookie customization parameters to A:A:P:BasicSession - Changed Apache parameter names to use "BasicSession" to prevent stomping on other session management libraries 0.13 Tue Nov 12 12:45:07 PST 2001 - Added Apache::AxKit::Plugin::AddXSLParams::BasicSession -- -man Michael A Nachbaur The best way to predict the Future is to invent it. PGP Public Key at http://www.nachbaur.com/pgpkey.asc PGP Key fingerprint = 83DC 7C3A 3084 6A21 9A3F 801E D974 AFB4 BFD7 2B6F - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Announce: AxKit::XSP::BasicSession 0.13
Hello all. This is a feature addition release. None of the existing functionality has changed, though I have added the plugin Apach::AxKit::Plugin::AddXSLParams::Session, using Kip Hampton's A:A:P:A:Request as a template. Now you can access your session keys from inside XSL stylesheets. (Woot!) I'm going to release it to CPAN sometime today (hopefully), but for those of you who can't wait, you can get it at my website. http://nachbaur.com/resources/axkit/AxKit-XSP-BasicSession-0.13.tar.gz -- -man Michael A Nachbaur The best way to predict the Future is to invent it. PGP Public Key at http://www.nachbaur.com/pgpkey.asc PGP Key fingerprint = 83DC 7C3A 3084 6A21 9A3F 801E D974 AFB4 BFD7 2B6F - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A:X:PerForm single-select with
Matt Sergeant wrote: On Friday, Nov 1, 2002, at 22:33 Europe/London, Michael A Nachbaur wrote: I simply love the and additions to PerForm; this solves many of the reasons why I had been reluctant to use PerForm. I simply love PerForm now, especially since I realized I can use ESQL inside my PerForm callbacks to do validation and updates. I don't think I've seen these additions. Is there a patch floating around somewhere or am I suffering from goldfish-brain syndrome again? Well, it's supported in A:X:PF 1.6, so I don't know if it's a special patch or anything, but, here's a snippet. If you want a better example (showing AxKit::XSP::Session, AxKit::XSP::ESQL and AxKit::XSP::PerForm all playing nice with eachother), lemme know. SELECT * FROM Account WHERE ID= 32 255 Some of PerForm was never finished, and never tested. You may be in unchartered territories. So please, patch away and send in your results! Thanks ;-) :-) Patch made and sent to axkit-devel. -- -man Michael A Nachbaur The best way to predict the Future is to invent it. PGP Public Key at http://www.nachbaur.com/pgpkey.asc PGP Key fingerprint = 83DC 7C3A 3084 6A21 9A3F 801E D974 AFB4 BFD7 2B6F - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
A:X:PerForm single-select with
I simply love the and additions to PerForm; this solves many of the reasons why I had been reluctant to use PerForm. I simply love PerForm now, especially since I realized I can use ESQL inside my PerForm callbacks to do validation and updates. I'm working on an administrative interface to manage a bandwidth accounting system, and need to provide a drop-down select box on a list of records. I was flying along at top-speed slamming out this XSP page when I put inside my element, only to realize that single-select doesn't support it. Aaack! On further reflection, it also seems to not support as well. Is there any way to work around this? Is there a profound reason why single-select wasn't updated, or was it just forgotten? Thanks. I'm willing to jump in and patch PerForm if necessary, but I'd like to have a heads-up before I blunder along a path others may have already tread before. -- -man Michael A Nachbaur The best way to predict the Future is to invent it. PGP Public Key at http://www.nachbaur.com/pgpkey.asc PGP Key fingerprint = 83DC 7C3A 3084 6A21 9A3F 801E D974 AFB4 BFD7 2B6F - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ANN: AxKit::XSP::BasicSession 0.12
Hello all, It's almost a full year since I released AxKit::XSP::Session, and have learned a great deal about making XSP taglibs since then. I was working on a project that, due to some technical issues beyond my control, no longer needed sessions, and therefore I didn't have the time to maintain my codebase. This weekend, I took it upon myself to finally fix my ailing code (mainly because I needed to use sessions for a new project ;-) I tried using Jörg's session taglib, but couldn't get it to work for my project. His taglib module seemed a bit overkill for what I wanted to do, so I threw my broken XSP taglib out the window and rewrote it using TaglibHelper. As far as my testing has gone, I believe to have ironed out the big bugs. Another thing I set out to fix was the namespace conflict between Jörg's and my module, both of them trying to use the same package name and URI. I therefore renamed AxKit::XSP::Session to AxKit::XSP::BasicSession, since it does very little compared to the new A:X:Session package. The URI has also changed to http://www.axkit.org/2002/XSP/BasicSession, since I'm not 100% compliant with the Cocoon2 specification. You can download the new module at : http://nachbaur.com/resources/axkit/AxKit-XSP-BasicSession-0.12.tar.gz If some of you would be willing to try it out and give me some feedback, before I submit this to CPAN, I'd appreciate it. Particularly, I'd like comments on my changes to the namespace and package names. Cheers! -- -man Michael A Nachbaur The best way to predict the Future is to invent it. PGP Public Key at http://www.nachbaur.com/pgpkey.asc PGP Key fingerprint = 83DC 7C3A 3084 6A21 9A3F 801E D974 AFB4 BFD7 2B6F - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Yet Another AxKit Badge
Christopher H. Laco wrote: > Fresh from the why-don't-you-stop-complaining-and-contribute department... > > http://today.icantfocus.com/blog/archives/entries/24/ > > I've made a powered by badge similiar to the ones at > http://www.modssl.org/docs/buttons.html > > They still need some compression tweaking. In both GIF and PNG versions. > > P.S. Could someone mirror these for a spell. The servers aren't going to > be 24/7 until next weekend? http://nachbaur.com/resources/axkit-badges -- -man Michael A Nachbaur The best way to predict the Future is to invent it. PGP Public Key at http://www.nachbaur.com/pgpkey.asc PGP Key fingerprint = 83DC 7C3A 3084 6A21 9A3F 801E D974 AFB4 BFD7 2B6F - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Callisto CMS
Alex McLintock wrote: > Someone recently mentioned Callisto CMS as a CMS which worked with AxKit. > > Since I am looking for more AxKit examples I thought I would check it out. > > Buit the online demo is down, and I can't find any kind of support email > address. There is a support mailing list for callisto at [EMAIL PROTECTED] (go to http://lists.sourceforge.net/lists/listinfo/callistocms-users to subscribe), as well as my personal email address. There's also a link to the sourceforge page for Callisto under the "Getting CallistoCMS" section of the website. Also, AFAIK the demo is running (it works for me at least). > Anyone have more info on Callisto? The version of Callisto running in the online demo is actually pretty old - I'm going to install the newer version today or tomorrow. If you have installation problems, there is an installation guide (that isn't finished) included with the distribution, as well as the mailing list archive which may help. If you have anymore questions, send an email to the Callisto mailing list, so that we don't spam all the AxKittens. :) -man Michael A Nachbaur - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ANNOUNCE: Callisto CMS 1.0 RC2 released
*sigh* I forgot to point you to the files. Here's the Sourceforge project page for Callisto: http://sourceforge.net/projects/callistocms/ If you're one of the unfortunate out there who are being blocked from Sourceforge by SmartFilter, I've placed the tarball on the Callisto website as well: http://www.callistocms.com/download/callistocms-1.0-rc2.tar.gz Cheers! -- OpenSource: Every now and then, you get what you don't pay for. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ANNOUNCE: Callisto CMS 1.0 RC2 released
Callisto CMS 1.0 RC2 adds a bunch of new features to the previous release. The two biggies are improved performance and directory navigation. The entire way configuration files are being managed has been gutted and refactored, so now all configuration data is being read on server startup, rather than per-request. This means if any changes are made to Callisto's configuration files, you need to restart Apache, but that's IMHO a small price to pay for the speed boost. Directory navigation has been added. Instead of only seeing your site from the user's perspective, you can now browse files as if you were using Nautilus or Explorer. You can add/delete/rename files and directories, you have a sidebar tree of your filesystem, and I'm currently working on multiple views (e.g. list, icon, details, etc). There are some other smaller changes in there, but that's the jist of it. Changes: Version 1.0-rc2 -- Wednesday, July 03 2002 --- - Major performance enhancements (removed URIHandler, and moved configuration logic to Apache sections) - Added a sidebar filesystem tree - Added a directory listing for filesystem browsing, file and directory creation, deletion and renaming - Performance enhancements to the SitemapTitle code - Made some minor changes to the sample site - Turned off debugging to FilesystemPie and SitemapTitle -- OpenSource: Every now and then, you get what you don't pay for. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
XML::XPath usage (was Re: Using XML::LibXML in an XSP page)
> yuck indeed. For id() to work you need the attribute defined as an ID > type in the local subset: I actually tracked the problem down. It was working, but as I use XML::XPath to modify, then save the document, the XML prolog and DOCTYPE definitions were getting lost. That was wreaking all sorts of havoc, with not having the DTD associated with the document, and with character set problems. Is there any better way to output XML from an XPath object, other than doing: XML::XPath::XMLParser::as_string($node); This only returns XML from the root-element down, and I lose my PIs, DOCTYPE and Prolog. I could string-munge the original document, and just prepend that to the XML returned from as_string(), but that sounds very crufty. > > Thanks everyone, and sorry for the spam. > > Spam? So it's *you* sending it all eh? I hope that Nigerian Scam is > making you a lot of money, because it's driving me nuts. Ha! I would never presume to be that evil...only a little evil (e.g. I run Windows2k in a VMWare window. *shudder* Photoshop is still nice and fast though) -- -man Michael A Nachbaur PGP Public Key at http://www.nachbaur.com/pgpkey.asc PGP Key fingerprint = 83DC 7C3A 3084 6A21 9A3F 801E D974 AFB4 BFD7 2B6F - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Using XML::LibXML in an XSP page
Hello all. I'm having a bit of difficulty with XML::LibXML. I need to be able to open and manipulate a DOM tree from within an XSP page, preferably with XPath. I would prefer to use XML::LibXML, but in reading the documentation, it said quite plainly that libxml2's options are global. So, since I'm using XML::LibXML in AxKit, if I try to use that module to parse a separate document in an XSP page, AxKit's callback subroutines are called instead. Is there any way to work around that limitation to do what I want? All I need to do is load an XML file, make a few changes, then spit it back out to a file. I've been using XML::XPath for this, and although its a tad slow, it's been working fine for me. But now I'm processing 150k+ XML documents, and XML::XPath takes *forever* to do some of the simplest operations. Right now I'm taking a sledge-hammer approach. I'm trying to find an element by an ID. I haven't been able to get the id() XPath function and getElementById subroutine to work, so I'm doing a //node()[@id='$id']...yuck. a) Does anyone have any idea on how I can get XML::LibXML to work along side AxKit? b) Anyone know of an alternative XML parser that has reasonably good support for XPath? c) Anyone know what I'm doing wrong with the id() and/or getElementById functions? I've defined a DTD for the document, but XML::XPath doesn't seem to ever generate it's array of IDs. Thanks everyone, and sorry for the spam. -- -man Michael A Nachbaur PGP Public Key at http://www.nachbaur.com/pgpkey.asc PGP Key fingerprint = 83DC 7C3A 3084 6A21 9A3F 801E D974 AFB4 BFD7 2B6F - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Regarding the differences between AxKit and Cocoon
On Wed, 15 May 2002, Matt Sergeant wrote: > On Wed, 15 May 2002, Truong, Nghia Huu wrote: > > On the behalf of my company I have tried to do some research on > > different types of content management tools on the Internet and I > > have found a lot of them. During this research > > I came across AxKit and Cocoon, and they both seemed to be great > > frameworks. Since this is the mailinglist for AxKit, I would like > > know if anyone of you may enlight me with > > the main differences between AxKit and Cocoon. > > AxKit is written in C and Perl. Cocoon is written in Java. I'd add to this that since AxKit is written in C and Perl, it is a lot more free-form than Java. Not to say that it's ad-hoc; quite the contrary. But, following the Perl motto TIMTOWTDI, you can control and use AxKit in various ways, depending on how you need to use it. And, I find it to be way faster, but I haven't done any official benchmarks, so don't take this comment as official. -- -man Michael A Nachbaur PGP Public Key at http://www.nachbaur.com/pgpkey.asc PGP Key fingerprint = 83DC 7C3A 3084 6A21 9A3F 801E D974 AFB4 BFD7 2B6F - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: httpd.conf
This threw me at first too. Mandrake Linux comes default with Apache configured using the proxied mod_perl method that is recommended in the mod_perl Guide. So, any perl requests are proxied to a separate apache process running on port 8200. commonhttpd.conf is common to both processes. httpd.conf is the Apache process running on port 80, and httpd-perl.conf is the one running on 8200. I'm not sure exactly how to make it proxy AxKit requests, since I only use Mandrake as my development/desktop machine (I go straight to port 8200). Hope this helps. On Thu, 2002-03-28 at 08:20, Ray Carlino wrote: > when using the new conf files > > > commonhttpd.conf > httpd-perl.conf > httpd.conf > > Which one do you put the perlmodule lines > > PerlModule AxKit > AddHandler axkit .xml > AddHandler axkit .xsp > AddHandler axkit .dkb > AxDebugLevel 10 > PerlSetVar AxXPSInterpolate 1 > > Ray > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- -man Michael A Nachbaur PGP Public Key at http://www.nachbaur.com/pgpkey.asc PGP Key fingerprint = 83DC 7C3A 3084 6A21 9A3F 801E D974 AFB4 BFD7 2B6F - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCE] Old Session plugin deprecated
With Jörg's new session plugin announcement, I'm declaring my session plugin officially deprecated. The main project I've been working on for the past 5 months makes heavy use of frames, which basically toasts any attempt to use Apache::Session (and all derivitives), so I haven't had any time to improve or fix my session module. If anyone submits patches to me, I'll try to keep it current, but I'd recommend JW's plugin, unless you have a compelling reason to use mine. -- -man Michael A Nachbaur PGP Public Key at http://www.nachbaur.com/pgpkey.asc PGP Key fingerprint = 83DC 7C3A 3084 6A21 9A3F 801E D974 AFB4 BFD7 2B6F - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] VIM syntax file for XSP
Sorry for the OT post, but does anyone have a VIM syntax file for XSP/Perl? I tried building one myself, but those config files are voodoo to me. I know the HTML::Mason syntax file uses a combination of the HTML and Perl syntax files, and just groups them together. Perhaps the same could be (has been) done for XSP? -- -man Michael A Nachbaur PGP Public Key at http://www.nachbaur.com/pgpkey.asc PGP Key fingerprint = 83DC 7C3A 3084 6A21 9A3F 801E D974 AFB4 BFD7 2B6F - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HTTP_USER_AGENT as a parameter?
> Now that i think about it... are the request/server/environment vars > something that folks will want, in general, to be available to their > stylesheets? If so, and I get enough "+1"s here, I'd be willing to ram > out and CPAN a Plugin that does all that stuff... +1 I don't know how many times I've had to do cheap hacks to gain access to this sort of information. -- -man Michael A Nachbaur PGP Public Key at http://www.nachbaur.com/pgpkey.asc PGP Key fingerprint = 83DC 7C3A 3084 6A21 9A3F 801E D974 AFB4 BFD7 2B6F - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AxKit Sessions taglib
On Sun, 2002-03-03 at 10:38, Tod Harter wrote: > On Sunday 03 March 2002 06:36, Sebastian Rahtz wrote: > > On Sun, Mar 03, 2002 at 12:27:09PM +0100, J?rg Walter wrote: > > > > I am looking for a sessions hqndling taglib that would handle cookies > > > > too. Anybody know where to find one? Thanks a lot, > > > > > > On my harddisk, and it's a good one, too. Does Automatic fallback to URL > > > tracking if cookies are not available. If I put it on CPAN tomorrow, > > > would that be OK? Otherwise i'd send you a preview. > > > > oh, yes please. can you put on CPAN and also on a web site > > for the impatient amongst us? > > The existing Session taglib also includes an AxKit plugin that does uses > cookies to set Apache::Session objects. Sounds like JW has a better > implementation, but if you have AxKit::XSP::Session you can already do what > you want. Yes, this taglib was written before JW's, and was intened just as a quick substitute while his (IMHO) better taglib was written. JW and I have discussed and coordinated our development, and have both decided that once his session module is finished, mine is to become deprecated. -- -man Michael A Nachbaur PGP Public Key at http://www.nachbaur.com/pgpkey.asc PGP Key fingerprint = 83DC 7C3A 3084 6A21 9A3F 801E D974 AFB4 BFD7 2B6F - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] XML::XPath usage
This isn't an AxKit question, but I don't know where else to ask. I'm using XML::XPath to modify an XML document. I'm loading the document, tweaking elements, and saving it back out to a file. (If anyone has better ideas for this, I'd like to know). I can edit elements just fine, but now I'm trying to move elements around (e.g., moving an element up or down one, or deleting elements). I can't figure out how to do this with XML::XPath. Any help would be appreciated. -- -man Michael A Nachbaur PGP Public Key at http://www.nachbaur.com/pgpkey.asc PGP Key fingerprint = 83DC 7C3A 3084 6A21 9A3F 801E D974 AFB4 BFD7 2B6F - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New AxKit Guide
On Wed, 2002-02-27 at 02:07, Matt Sergeant wrote: > I've now gotten permission from O'Reilly to publish the AxKit Guide that I > wrote as an appendix to one of their upcoming books. It needed a bit of > fixup for AxKit publishing (as the original is in POD, ugh!), so there may > be some buggettes here and there (like the fact that footnotes aren't > linked up yet), but it should be fairly useful to new users. > > http://axkit.org/docs/guide.dkb > > Please let me know what you think - if all is good I'll add a link from > the sidebar. Good job! I think this is perfect for the sidebar. Do you forsee this growing into something like the mod_perl Guide? -- -man Michael A Nachbaur PGP Public Key at http://www.nachbaur.com/pgpkey.asc PGP Key fingerprint = 83DC 7C3A 3084 6A21 9A3F 801E D974 AFB4 BFD7 2B6F signature.asc Description: This is a digitally signed message part
Re: search engine indexing
Well, as long as the generated HTML complies with the search engine indexing rules, you should be fine. Try to avoid using the query string (at least for the important aspects of your site), and make liberal use of the tags. If you do need to pass information to your XSP pages, you can always use the Path_Info field (e.g. /foo.xsp/argument). For instance, I have "Printable" versions of every page, so on those pages I set the following tag in the header: Setting your "Keywords" and "Description" meta tags wouldn't hurt either. Just my USD$0.02. -man Michael A Nachbaur On Fri, 2002-02-15 at 21:03, Ray wrote: > I am creating an xml based dynamic web site using axkit and need to know > how the major search engines handle indexing dynamic xml pages? I know > they have problems with asp because of the ? characters. > Thanks for your help > Ray - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] XML::LibXML "Can't call method _fix_extra"
Sorry for the OT message, but I couldn't figure where else I'd find a large
group of people who use XML::LibXML (and I didn't want to email Matt
directly).
I have a series of Apache handlers (Perl{Trans,Access,Authen}Handler) that
all use XML::LibXML to load external configuration files to determine things
like authentication, authorization, etc. I've run into a strange problem
that I haven't found documented anywhere.
My code runs fine the first request. However, On the second request I get
the following message in my error_log:
[error] Can't call method "_fix_extra" on an undefined value at
/usr/lib/perl5/site_perl/5.6.0/i386-linux/XML/LibXML.pm line 202.
I have libxml2 2.4.13 and XML::LibXML 1.31. These handlers are defined at
the level, while I have AxKit defined at a level
under that. The only handler I'm getting this error in is the
PerlTransHandler, but as its the first handler called, none of the other
handlers are called. Any6way, the TransHandler I've defined creates one
XML::LibXML parser, and loads two XML documents (e.g. I load one XML file,
undef it's document handle, then load a second under a different variable,
then undef it as well). It sounds like a garbage collection problem to me,
but I can't seem to track it down. I only have a basic understanding of XS,
and the rest is voodoo to me.
Any help would be appreciated.
Michael A Nachbaur
-man
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: returning a y:tag from x: taglib (fwd)
> > I would think this is the kind of application where you would want
"deeper"
> > pipelines... In other words you could have 2 levels of XSP processing,
the
> > first level can deal with taglib x, and the 2nd can deal with taglib y.
In
> > many cases you can simply use 2 namespaces and combined functionality of
> > several taglibs, but there are cases like PerForm where that may not be
a
> > good solution, so hence deeper pipelines, maybe even something like
XSP ->
> > XSLT -> more XSP -> more XSLT...
>
> Ugh, SAX based is faster and cleaner. IMHO, of course. SAX based taglib
> combining is done in parallel, compiled, and just plain works. The code is
> simple. Really simple.
I disagree. I think this is another example of procedural vs. functional
programming. XSLT is a functional langauge, Perl is procedural. I would
much rather componentize my work in small, re-usable chunks, and to hell
with performance. My time is more valuable than an extra server or two.
So, I would like to have an XSP page describe, for instance, the structure
of a form. Then, have an XSL stylesheet process that form to do the grunt
work of setting up the validation rules, database accesses, etc. The XSL
stylesheet could then output another XSP page which handles the actual form
(which is displayed by a final XSL stylesheet). Want to have repeatable
elements in your input form? Its just an extra parameter to the XSL
stylesheet and a @repeatable="true" in your first XSP page, and it adds more
validation code for that field. It would save me quite a bit of time, and
is still clean (XSLT is a lot easier than
$this->is->{a_really}->long->object).
Therefore, I think this way of doing things is still valid. Is there any
way of implementing this? (I don't see why not, except the Perl code from
the second XSP page couldn't be cached).
-man
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: session taglib
> I am not sure how to load a session, instead of creating a new one. > Suppose I use the cookie taglib to save the session ID, and everything > about the user in the session -- how would I get all the data about > the user, once I receive his ID from the cookie ? Well, the session taglib actually comes in two parts: a) the taglib, which gives you access to an already-loaded session, and b) the plugin that loads/creates the session. The taglib doesn't currently support sessions creates inside your XSP page (so, using the cookie taglib to set the session ID won't do anything). Apache::AxKit::Plugins::Session will load any existing session data, if you configure it to point to the appropriate data store, and your cookie ID matches the one used by the Session plugin (I think it uses SESSION_ID). Look at the POD documentation for Apache::AxKit::Plugins::Session for information on how to configure it. The idea behind this taglib, was to make session access transparent to the XSP developer; no special code needs to be added to an XSP page to enable sessions. Does this answer your question? If not, feel free to ask again. -man - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Site-search tools friendly with AxKit?
> I did succeed in getting htdig to work for me, exactly as you suggest. > Step one is calling htsearch from a simple Apache::Registry file (just a > pipe). > Step two is writing templates in XML instead of HTML. > Step three is some search and replace because htdig inserts HTML form > tags in HTML syntax. > Step four is using the Apache::Filter stuff. Any chance you can post the htdig output templates that you used? I'm thinking of outputting either RDF or RSS (can't remember off the top of my head which is more applicable for search results), but having a starting place would be helpful. -man - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Site-search tools friendly with AxKit?
Is anyone familiar with any search/indexing programs that are AxKit-friendly? I'm looking at ht://Dig, but there's no way I'll be able to integrate it with AxKit without some serious hacks. Are there any good indexing / searching programs available that I could plug in with AxKit? For instance, something callable from an XSP page, or some mod_perl handler that I can use Apache::Filter? What I'm looking for is something that, when it performs a search and comes up with results, that I can pass through an XSL stylesheet to display search results using my look&feel. Thanks in advance. -man Michael A Nachbaur - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
