You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Robert Zeigler (JIRA)" <de...@tapestry.apache.org> on 2008/03/18 18:25:25 UTC
[jira] Created: (TAPESTRY-2275) Provide BlockSource service for
fetching blocks from arbitrary pages
Provide BlockSource service for fetching blocks from arbitrary pages
--------------------------------------------------------------------
Key: TAPESTRY-2275
URL: https://issues.apache.org/jira/browse/TAPESTRY-2275
Project: Tapestry
Issue Type: Improvement
Components: tapestry-core
Affects Versions: 5.0.12
Environment: any
Reporter: Robert Zeigler
Priority: Minor
In complex rendering schemes, the components to be rendered may be contained on a page other than the currently "active" page or component.
There is not, however, currently a non-trivial or non-"internal" method of obtaining an arbitrary block from an arbitrary page. This will be necessary to support complex rendering schemes where the page from which to obtain the block is unknown until runtime.
An example of the complex rendering and page/block handling is found in Tapestry's own "PropertyEditor" and "PropertyDisplay" components.
These components make use of the BeanBlockOverridesSource to fetch their respective edit and display blocks.
Although it is possible to contribute display and edit blocks for use in the BeanBlockOverridesSource, it is undesirable to do so in many situations, owing to "Unintended Consequences".
For example, a complex rendering scheme may allow for pluggable "layouts". New layouts could be added by dropping in a jar with a set of contributed layouts.
These layouts would be contained in their own page or pages, and the correct layout selected at runtime. Although such a scheme could use the BeanBLockOverridesSource to access the layouts, it seems like a separate concern. This is not a "bean" that needs to be edited or displayed, nor is there an associated "DataType".
I propose a new public service: BlockSource
with two methods:
Block findBlock(String pageName, String blockId);
Block getBlock(String pageName, String blockId) throws BlockNotFoundException;
BeanBlockOverridesSource would be refactored to use this service.
This would keep the implementation and details of pages (the PageCache and so forth) internal, but still allow for the flexibility needed for complex rendering schemes.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Resolved: (TAPESTRY-2275) Provide BlockSource service for
fetching blocks from arbitrary pages
Posted by "Robert Zeigler (JIRA)" <de...@tapestry.apache.org>.
[ https://issues.apache.org/jira/browse/TAPESTRY-2275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robert Zeigler resolved TAPESTRY-2275.
--------------------------------------
Resolution: Invalid
Apparently I just didn't look through service list long enough when I originally opened this issue.
The functionality described in this issue can be achieved by using ComponentSource, as in:
componentSource.getPage("SomePageName").getComponentResouces().findBlock("SomeBlockName");
> Provide BlockSource service for fetching blocks from arbitrary pages
> --------------------------------------------------------------------
>
> Key: TAPESTRY-2275
> URL: https://issues.apache.org/jira/browse/TAPESTRY-2275
> Project: Tapestry
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.0.12
> Environment: any
> Reporter: Robert Zeigler
> Priority: Minor
>
> In complex rendering schemes, the components to be rendered may be contained on a page other than the currently "active" page or component.
> There is not, however, currently a non-trivial or non-"internal" method of obtaining an arbitrary block from an arbitrary page. This will be necessary to support complex rendering schemes where the page from which to obtain the block is unknown until runtime.
> An example of the complex rendering and page/block handling is found in Tapestry's own "PropertyEditor" and "PropertyDisplay" components.
> These components make use of the BeanBlockOverridesSource to fetch their respective edit and display blocks.
> Although it is possible to contribute display and edit blocks for use in the BeanBlockOverridesSource, it is undesirable to do so in many situations, owing to "Unintended Consequences".
> For example, a complex rendering scheme may allow for pluggable "layouts". New layouts could be added by dropping in a jar with a set of contributed layouts.
> These layouts would be contained in their own page or pages, and the correct layout selected at runtime. Although such a scheme could use the BeanBLockOverridesSource to access the layouts, it seems like a separate concern. This is not a "bean" that needs to be edited or displayed, nor is there an associated "DataType".
> I propose a new public service: BlockSource
> with two methods:
> Block findBlock(String pageName, String blockId);
> Block getBlock(String pageName, String blockId) throws BlockNotFoundException;
> BeanBlockOverridesSource would be refactored to use this service.
> This would keep the implementation and details of pages (the PageCache and so forth) internal, but still allow for the flexibility needed for complex rendering schemes.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org