Hi!
> There some logic behind it ... basically, anything that doesn't need
> to change once it's on the server is rendered by the client and
> uploaded
Yeah, sure, but it sometimes is a _bit_ irritating, especially if they
pull their "use javascript that dynamically rewrites document source"
trick :-)
> It shouldn't be too hard. All you need to do is:
Oh, that's not the problem, I only hoped it might be easier. It's not
really important, it's just that Jutta would like a link directory for
her pages. I already did a little RSS-to-HTML-via-XSLT tool for her to
render dynamically her RSS feeds on the other server.
I am actually thinking about some way to integrate 4Suite into PyCS to
enable dynamic rendering of XML into HTML with XSLT. XSLT isn't the best
way to work with XML, but it's one where you have lots of documentation
for people to read and use. And since Radio (and bzero) already produce
XML files, it would fit nicely into the grand scheme.
bye, Georg
> >Check out the HTML source of linksammlung.html - it looks like there's
> >an app running on subhonker6 that downloads .opml files and generates
> >HTML directories out of them. Here's the URL to do it for your page:
>
> Aaarghl. Those Userland-programmers are driving me crazy with their
> linking/fetching/transforming/stuffing/distributing stuff. Can't they
> decide on what system to run their code? :-)
Heh :-)
There some logic behind it ... basically, anything that doesn't need
to change once it's on the server is rendered by the client and
uploaded.
Anything that needs to be more dynamic is done on the server. In this
case, your OPML could be generated by the client but the HTML had to
be done by the server.
> Ok, so that's not so easy to hack up, this calls for a bit more action.
> Hmm.
It shouldn't be too hard. All you need to do is:
- fetch the OPML file (check authentication, validate filename, read file)
- parse OPML into a tree
- figure out which branch to display
- display branch, putting in links as required
Cheers,
Phil :)
Hi!
> Check out the HTML source of linksammlung.html - it looks like there's
> an app running on subhonker6 that downloads .opml files and generates
> HTML directories out of them. Here's the URL to do it for your page:
Aaarghl. Those Userland-programmers are driving me crazy with their
linking/fetching/transforming/stuffing/distributing stuff. Can't they
decide on what system to run their code? :-)
Ok, so that's not so easy to hack up, this calls for a bit more action.
Hmm.
bye, Georg
Georg:
> I created a little directory at
> http://hugo.muensterland.org/stories/2002/12/18/linksammlung.html
>
> There you can see the problem: it references subhonker and not PyCS. So
> the spontanous question arises, would it be possible to hack this to use
> a different Community Server? Maybe some of you already used this
> feature and know about it?
Hi,
Check out the HTML source of linksammlung.html - it looks like there's
an app running on subhonker6 that downloads .opml files and generates
HTML directories out of them. Here's the URL to do it for your page:
http://subhonker6.userland.com/rcsPublic/viewDirectory/?flIcons=true&flLinkText=false&flMinimalTemplate=false&flXmlButton=true&remoteInclude=true&url=http%3A%2F%2Fhugo.muensterland.org%2Fgems%2FMeineLinks.opml
You could code up a replacement for viewDirectory inside PyCS if you
like, although fetching remote URLs without blocking is a little
trickier inside Medusa than it is under multi-threaded Frontier or
multi-process Apache. If you restrict it to local files (then, say,
call it with something like
http://foo/system/viewDirectory.py?usernum=0000001&path=/gems/MeineLinks.opml)
it wouldn't be too hard though... all you need to do is parse OPML and
create HTML.
Rick at techno-weenie.com might have done something about this; I
remember he was hacking some PHP outline stuff a while ago.
Cheers,
Phil :)
Hi!
Radio Userland allows rendering Outliners as HTML Link Directories. A
description is at http://radio.outliners.com/directoryOutliner
I created a little directory at
http://hugo.muensterland.org/stories/2002/12/18/linksammlung.html
There you can see the problem: it references subhonker and not PyCS. So
the spontanous question arises, would it be possible to hack this to use
a different Community Server? Maybe some of you already used this
feature and know about it?
And if it can be hacked, does it use server capabilities we would have
to implement? Especially the link suggestion would be nice.
bye, Georg
Hi!
> ZOpen-X blog. That looks pretty good, and has a standalone version
> ("Catalog") that might be able to be plugged in. It adds some
> overhead (requires the ZODB) but this is to be expected when you have
> a search DB.
Hmm. ZODB might not be really that bad - we could use that as base DB,
instead of Metakit and so get the Unicode stuff up and running, as ZODB
is fully Unicode compliant, if I recall correctly.
But ZODB has one rather big disadvantage: ZODB never shrinks. It only
grows. Write new records and it grows. Store new objects and it grows.
Change Attributes and it grows.
To shrink you have to call an special maintenance code that actually
copies out all active objects into a new ZODB and then switches DB files
underneath the running server. That's something that always has bothered
me a bit with our production environment (we make extensive use of
ZODB). But it is quite stable, so this problem is more one of style and
not function ;-)
bye, Georg
Hello all,
Here's a note (for the ppl who haven't been following scripting news &
zopenx) about stuff that's been going on off the list over the last
few days, mainly to do with search engines.
I'm hosting a (private) community server for RealWorld Systems (in
Canada) and they need a search engine. This is a good opportunity to
plug a decent search interface into PyCS.
There are loads of possibilities ... I've tried standalone packages
(mnoGoSearch and ht://Dig) and ht://Dig looks quite good. Now I want
to hack something together to get the search playing nicely with the
page viewing permissions. Someone who can only see one or two blogs
shouldn't see search results outside those.
The obvious way (and probably the quickest) to do this would be to
turn ht://Dig's 'htsearch' module into a Python extension, and to
create a system/search.py that would call back into that and only
display matches that are valid for the current user.
The disadvantage here is that ht://Dig is GPL, so this would have to
be a separate plugin for PyCS rather than an integral part of it.
(I'd make an 'opt' directory in the CVS for optional things like
this). Including it would make the GPL cover your copy of PyCS, which
doesn't worry me, but I don't want it becoming the default license for
things.
Robert Barksdale pointed out the very cool ZCatalog module on his
ZOpen-X blog. That looks pretty good, and has a standalone version
("Catalog") that might be able to be plugged in. It adds some
overhead (requires the ZODB) but this is to be expected when you have
a search DB.
My plan of attack at the moment (as speed is a priority) is to do the
ht://Dig option, but I would prefer to use Catalog in future as it
will fit in much better with the system.
Comments?
If you feel like reading more, I've written a whole heap (on Second
p0st) about this over the last couple of days:
Search engines:
http://blogs.salon.com/0000002/2002/12/17/#200212172
mnoGoSearch on FreeBSD:
http://blogs.salon.com/0000002/2002/12/17/mnogosearch_on_freebsd.html
Building a search engine for PyCS:
http://blogs.salon.com/0000002/2002/12/17/search_engine_in_python.html
Adapting existing code:
http://blogs.salon.com/0000002/2002/12/18/adapting_other_search_engines.html
ht://Dig on FreeBSD:
http://blogs.salon.com/0000002/2002/12/18/htdig_on_freebsd.html
Cheers,
Phillip :-)
