On Sunday, December 7, 2003, at 12:32 pm, Kjetil Kjernsmo wrote:
On Sunday 07 December 2003 12:44, Mike Chamberlain wrote:
The problem your seeing is a bug/feature of axkit as it currently works.
In order to setup a pipeline, axkit needs to know what sort of xml it's
looking at,
so it sniffs the content [ first call to provider ], then having built
the pipeline
it reads the content again [ second call ].
OK. But it is not starting from scratch? I mean, by creating a new Apache::AxKit::Provider (or rather the subclass thereof) object?
No, it reuses the same provider within the same request cycle.
I'm adding data to $self, i.e. this object, so if this object was destroyed,
my provider should construct all my other objects again, currently by reading
everything from a DB, and so I shouldn't have a problem.
The problem is that the way providers/axkit currently work, it's not an
easy problem
to fix without fundamentally changing the way a few things work.
OK. Just an idea that came to my mind, would it make sense to mandate a method
to tell AxKit what sort of xml it should be expecting, and just call that
instead of asking for the full content?
That's one possible approach. Some providers will know that answer, and maybe
extending get_styles to make use of that would solve some part of the problem,
however that's not the case for all providers. It's the get_styles method
on providers which is the real problem, chances are a working solution would
probably extend or modify it. The real problem comes when you have to be
backwards compatible, as the API is published.
At the moment providers are not cached, so if possible you could just stash the results away from the first call to return in the second. Obviously this isn't a great long term solution, since if ever anyone optimises axkit to cache providers then potentially lots of things could break.
Yup... Anyway, since I store stuff in $self, and $self is apparently not
destroyed between the calls (?), I could just check if all the needed data
have been loaded allready. That's the robust way of doing it anyway, but
there are those awful time constraints that I'm sure I'm not the only one who
suffers under... :-)
BTW, providers are not cached at all...? So, mtime and that stuff is sort of a
future-proofing thing...? Or have I missed something...?
The same provider would be used in the get_styles request and the content request.
On a new HTTP request, it will be a new provider instance.
Mike.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
