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

List:       mason
Subject:    [Mason] comp roots, anonymous components, etc.
From:       Jonathan Swartz swartz () transbay ! net
Date:       1999-05-01 22:24:10
[Download RAW message or body]

Okay, after reading Philip's email and others, I've tried to pinpoint and 
flesh out several new feature candidates. Let's keep the discussion going.

1.  Generalized, object-oriented component model

Store components in a new class, HTML::Mason::Component.  Allow new 
component objects to be created on-the-fly, like anonymous subroutines:

	my $c = new HTML::Mason::Component (script => '...', [path => '/foo/bar']);
	mc_comp ($c, ...);         OR         $c->execute (...)

Components would no longer need to be associated with a single file under a 
component root.  This would allow you to pull component source from 
arbitrary files, database, etc. It would also make it easier to associate 
meta-data with components.  As always with objects, we must be careful not 
to cause a significant performance degradation.

2.  Multiple component roots

Allow the component root to be a list of paths that are checked in order 
like Perl's @INC.  This is useful for keeping a subset of personal 
components that "overwrite" the main components. For example if my component 
root is

	('/home/swartz/comps', '/usr/local/www/docs')

and I execute

	mc_comp ('/sales/index.html')

Mason will check the following file names, in order, for a component source 
file:

	/home/swartz/comps/sales/index.html
	/usr/local/www/docs/sales/index.html

My feeling is that regardless of which filename is found, the component path 
is still just /sales/index.html as far as the user and most of Mason is 
concerned. There is only one object and one cache file. The user cannot 
choose to call one of these files as opposed to the other, and generally has 
no concept of which source file has been used. In other words, this is a 
single component with two possible versions, not two distinct components.

Relative paths are consistent. If from inside /sales/index.html someone 
executes mc_comp ('header'), Mason searches for:

	/home/swartz/comps/sales/header
	/usr/local/www/docs/sales/header

3.  Resolvers

Currently a component path passed to mc_comp always resolves to a file. 
Allow the creation of multiple "resolvers", subroutines which take a 
component path and return a component object.  We don't care where the 
resolver gets its component source as long as it eventually returns an 
object or an error code.

Allow resolvers to be registered with path prefixes.  For example, I might 
register the prefix "/db" with a resolver that looks in the database.  Or I 
might register different prefixes to use different sets of component roots 
-- this is something that Philip alluded to.

Have to admit that, right now, I can't think of any great motivations for 
this feature other than "it's cool".  :-)

Jon



======================================================================
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]