luxor / chora
Cynic
cynic@mail.cz
Thu, 09 Aug 2001 08:40:30 +0200
Hi there,
I'm thinking about luxor / chora integration, and since I'm only
getting to know chora, I've got a few questions...
<soapbox>
First, let me say that the fact that code in Chora that actually
does something (i. e. besides declarations) is spread among files
directly requested from browser and files included from these
makes it really hard to understand the code. Looks like the only
one who's been working on Chora so far is Anil, so this is
understandable (no need to read other people's code, no problems),
but I'd be extremely happy if it'd be possible to reorganize the
flow so that the includes contain only class declarations etc.
Opinions?
Second, Chora is terribly heavy. For example, a CVSLib_File object
for a file with two revisions and a single branch (HEAD) contains
seven full CVSLib objects. print_r() representaion of that object
has 45kB, and it doesn't include the method hashes. I know this
doesn't say much, but you get the idea. Are such heavy objects
really necessary? I believe this slows down execution significantly.
</soapbox>
Now, back to work.
1) What variable or public object property contains / accessor returns
the filepath as contained in the URLs? To make myself clear:
given this URL, I want to get the "/luxor/images/back.gif" part:
http://localhost/horde/chora/co.php/luxor/images/back.gif?r=1.1.1.1
2) I've read in the GOALS file that you want to abstract the diff
handler so that e. g. image revisions are displayed side by side.
IMO the first step in this direction would be generalizing co.php
by moving the actual output of the revisions to the appropriate
methods in the MIME handlers. That way checkouts of images could
look just like checkouts of html/php/text files:
$raw = = Horde::getFormData('raw', 0);
if (0 == $raw) {
$pretty->renderWrapped();
# or whatever
# will do:
# include $registry->getTemplatePath() . '/common-header.inc';
# include $registry->getTemplatePath() . '/checkout/header.inc';
# print '<image src="...&raw=1" ... />' for images, the first
# branch of the "if ($pretty->getType()..." in the current
# implementation for text/*, and whatever is appropriate for
# other types
# include $registry->getTemplatePath() . '/checkout/footer.inc';
# include $registry->getTemplatePath() . '/common-footer.inc';
} else {
$pretty->renderRaw();
# or whatever
# e. g. for images, this would basically be the "else" branch of
# the current "if"
}
Now luxor questions.
1) I should probably just wait till I get some sleep, but out of sheer
curiosity: let's say luxor would be registered handler for .php files.
Scenario:
index.php includes 'foo.inc' and 'bar.inc'. index.php calls blah(), which
is defined in foo.inc 1.1, and bar.inc 1.1.5 (moved from foo.inc).
index.php 2001-05-01 1.1
2001-06-01 1.2
foo.inc 2001-05-01 1.1
2001-05-15 1.1.5
bar.inc 2001-05-01 1.1
2001-05-15 1.1.5
When you checkout index.php rev. 1., and display the ident ifno for blah(),
what should it display w. r. t. its definition? Should it display "defined
in foo.inc" or "defined in bar.inc"? I. e., should it base the ident query
on the date of either revision? The problem is, that unless I overlooked
something, either way would mean that if you got back to index.php going
through several different files, always querying the latest concurrent
revision of a file linked linked to the current one, you could end up
several revisions away from the original one. I guess the way to go would
be to get the time just before the next revision to index.php was checked
in, and do checkouts based on the timestamp from then on.
Do you see any problems with this?
cynic@mail.cz
-------------
And the eyes of them both were opened and they saw that their files
were world readable and writable, so they chmoded 600 their files.
- Book of Installation chapt 3 sec 7