[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mason
Subject:    [Mason] Thoughts on the component resolver
From:       Philip Gwyn liste () artware ! qc ! ca
Date:       1999-05-07 23:54:04
[Download RAW message or body]

I've been diging around some more, to fix my sub-section code.  It now respects
the mc_comp('/something.mason'); syntax.  

Here are some complications:
- There are 2 main "entry points"
  HTML::Mason::Interp::exec_next (via ApacheHandler or mc_comp)
  HTML::Mason::Interp::load (via ApacheHandler, exec_next or various mc_comp*
        routines)

- component name is always expected to be a string that contains a full path
name

- Interp::load is used as a general loader (exec_next) *and* as a test to see if
a component can be loaded (most other cases).  These two operations should be
seperate.

This is what I see the Resolver doing :
- Resolver will take a absolute (under comp_root) or relative name

- Will decide what the full path name is, what the cache name should be, what
sub-section it is in.  This means the component name becomes a hashref to this
info.  Lots of code will have to be corrected.

- Fall back to a dhandler if the component file isn't available (is this only
available to ApacheHandler?).

- Will decide weither a component is loadable or not.  
       (via $INTERP->loadable()?)

- Resolver will have to know about Interp->locals (aka $INTERP->{stack}) so that
components won't be able to call components in other sub-sections.

- Also, maybe the resolver should decide what parser/interpreter pair will be
used.  Desicion based on prefixes (/db/, /http/) or extention (.xml, .html) 

Here are some senarios for having several parser/interpreter pairs : 
a- the component's contents could be pulled over the net, from a DB, via HTTP,
etc and then parsed by HTML::Mason::Parser

b- the component's executable form (ie the perl code that goes in the
object file) could be pulled over the net, from a DB etc then interpreted with
HTML::Mason::Interp.  For instance, a complicated structure could be populated
from a database then Data::Dumper into a component.

c- the component's output could be pulled from a DB, via HTTP, from a POE
kernel, etc.

Am I making any sense?

-Philip
======================================================================
To unsubscribe: echo unsubscribe | mail mason-request@netizen.com.au
Charter/FAQ/Archive: http://www.netizen.com.au/resources/lists/mason/

[prev in list] [next in list] [prev in thread] [next in thread]