Bug 43813 - ResourceTypeModule cannot work with proxy
Summary: ResourceTypeModule cannot work with proxy
Status: NEW
Alias: None
Product: Lenya
Classification: Unclassified
Component: Miscellaneous (show other bugs)
Version: Trunk
Hardware: Other other
: P2 major
Target Milestone: 2.0.1
Assignee: Lenya Developers
URL:
Keywords:
Depends on:
Blocks: 43750
  Show dependency tree
 
Reported: 2007-11-08 07:08 UTC by J
Modified: 2007-11-19 05:23 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description J 2007-11-08 07:08:01 UTC
the current implementation provides a {resource-type:httpSchemaUri} that is
supposed to return a URL suitable for a browser to retrieve a schema.
it only takes context into account, not proxy.
the quick fix is to use an OutgoingLinkRewriter.

but it might be more future-proof to do away with the differentiation between
schemaUri and httpSchemaUri anyways and to define a standard location
modules/<resourceType>/schema.rng that all resource type modules have to provide.
that way, we can also get rid of the clunky custom fallback resolver in the module.
Comment 1 J 2007-11-08 08:47:50 UTC
a quick grep indicates that bxe is the only user of
{resource-type:httpSchemaUri}, and that {resource-type:schemaUri} is not used at
all.
should we just deprecate both and require all doctypes to provide a
"/modules/<resourceType>/schema.rng" in their sitemaps?
Comment 2 Andreas Hartmann 2007-11-08 08:57:31 UTC
The problem is that a module can contain more than one resource type. For
instance the forrest module will contain resource types for "normal", FAQ,
changes, ... documents.
Comment 3 J 2007-11-08 12:09:05 UTC
(In reply to comment #2)
> The problem is that a module can contain more than one resource type. For
> instance the forrest module will contain resource types for "normal", FAQ,
> changes, ... documents.

but is that worth it? wouldn't it simplify things a lot if we mandate one
doctype == one module? afaik multiple doctypes per module are not widely used,
and splitting them would be trivial.
then we could get rid of some code and replace another layer of configuration
with convention. the fallback resolver hack is really frightful, and totally
unnecessary imho given that we could just as well handle the stuff in sitemaps,
where all the glorious resolvers are available without limitations and hacks.
wdot?

that said, i'd also like to re-discuss the formats post 2.0. do we really need
formats as a configurable with a corresponding input module, or could we just
use matchers in the resource type module sitemaps and define these as an API?
reduces overhead, gets rid of indirection, makes stuff more self-explanatory.
Comment 4 J 2007-11-13 12:25:20 UTC
for now, i have removed the context from the module. this implies you need to
wrap it in a {proxy:} call. not very logical (httpSchemaUri sounds like it
delivers a complete http://.... uri), but works for now. i'm still thinking this
should go altogether.

andreas, if you think multiple doctypes per module are important, let's implement
/modules/<moduleName>/schemas/<resourceTypeName>.rng in every doctype module
sitemap and get rid of the configuration and input module. wdyt?
(i'm not fundamentally opposed to an input module in itself, i just think
second-guessing the meaning of fallback:// is not a concern of such a module -
if it can be avoided, i could live with it. although it's configuration instead
of convention.)
Comment 5 Andreas Hartmann 2007-11-19 05:13:17 UTC
(In reply to comment #4)

> andreas, if you think multiple doctypes per module are important, let's implement
> /modules/<moduleName>/schemas/<resourceTypeName>.rng in every doctype module
> sitemap and get rid of the configuration and input module. wdyt?

That would be very convenient, but the problem is that we don't know which
module the resource type is provided by ... Maybe we could introduce a
convention for resource type names:

  {module} if only one resource type is provided by the module
  {module}.{resourceType} if multiple resource types are provided

The module name could be extracted by the resource type module:

  {resource-type:module:{doc-info:....:resourceType}}

But then it's only a small step to the situation which we have now.
Comment 6 Andreas Hartmann 2007-11-19 05:16:43 UTC
But we could go one step further and require the following syntax for resource
type names:

  {module}.{resourceTypeName}

This could be matched in the sitemap:

  .../*.*/...

<map:generate src="{proxy:/modules/{1}/schemas/{2}.rng}"/>

Unfortunately, all document meta data would have to be updated when the names of
the existing resource types change.
Comment 7 Andreas Hartmann 2007-11-19 05:18:19 UTC
OTOH, this means that we would address the module using its short name, which
ultimately renders the module package useless.
Comment 8 Andreas Hartmann 2007-11-19 05:23:13 UTC
If we support both {resourceType} and {module}.{resourceType} we would have to
provide two pipelines:

<map:match pattern=".../*.*/...">
  <map:generate src="{proxy:/modules/{1}/schemas/{2}.rng}"/>

<map:match pattern=".../*/...">
  <map:generate src="{proxy:/modules/{1}/schemas/{1}.rng}"/>

IMO this is acceptable.