Hi
I have checked the spec and read the documentation related to multi-templating.
In few words, what I can see is the reduced multi-templating proposal tries to
do some simplifications, but each one has a "cost" involved. Below is just my
interpretation of the proposal with some observations that it could be good to
discuss. The intention is make proper clarifications about how this should
work.
For example, it is clear the reduced multi-templating proposal suppose only
one multi-template can be applied in one view at the same time. So, there is
a constant that is "application scope" that specify a resource library that
defines the multi-template contract for the whole application and later there
is a resource prefix that helps to differentiate between "contract
implementations of the multi-template".
With this structure, it is possible to define multiple "contract
implementations
of the multi-template" in different jars, just changing the resource prefix. So
in jar A you can have things in:
META-INF/resources/my.multitemplate.library/prefixA/banner.png
and in jar B to change the banner just write:
META-INF/resources/my.multitemplate.library/prefixB/banner.png
So, the resource prefix is something that works like the Locale for a view. A
view only has one resource prefix assigned. This concept suppose that the
request path for Resource instances needs to be updated in the same way we did
for locale (add a query param loc=... so Resource instance can be
built correctly).
Compared with the full multi-templating proposal, the simplifications done are:
- If multi-templating is an "application scope" concept (only one
multi-template
contract per application, but multiple implementations), the advantage is there
no need for any configuration about the relationship between a view and the
multi-template to apply for that view, but the disadvantage is it limits
reusability, because it is not possible to set multiple contracts in the same
application (for example one for layout, one for skinning and so on).
Please note with the reduced multi-templating proposal, the libraryName is used
as a way to group different multi-template contract implementations, but the
resource prefix is used to identify contract implementations. With a full
multi-templating solution, the same concept should be provided, but it is a
little bit tricky to get it done without introduce additional configuration
files.
- There is a simple "inheritance" relationship between multi-template contract
specification and the implementation (look the resource with prefix and if it
is not found, look for the resource without prefix). The question is if this
relationship is enough or not for the intended scope of multi-template usage.
- The concept of "resource prefix" simplify the relationship between the view
and the multi-template contract implementation to apply. The advantage is it is
very simple to understand, but it can be a little bit tricky to implement it,
because it requires to do some changes over Resource class, like has been
mentioned before.
Basically, the discussion about how this feature should looks like is about
these three points. The position of the EG about them will decide the final
result. Personally, I'm willing to support full multi-templating
proposal, because
I believe it is possible to design an intermediate solution, but at the end is
up to the members of the EG to decide which route should be taken.
best regards,
Leonardo Uribe
2012/11/2 Edward Burns <edward.burns_at_oracle.com>:
> Hello Volunteers,
>
> I've created a snapshot of the spec to serve as Public Review Draft
> Release Candidate 1 [1]. As before, the only difference between [1] an
> the nightly in maven.java.net is that [1] has the PDF built in. That's
> important in this case because I'm asking you to take a look at the PDF
> in particular.
>
> I have a lot more work to do with it but it's suitable for review in our
> group here.
>
> There is one topic I need your help in deciding: the scope of the
> multi-templating feature. Back in May I wrote some text in the spec
> prose document and made an initial commit on the feature to the RI.
>
> Since then, work on this feature has been stop-and-start. During one of
> the "start" phases, we discussed the feature in an EG conference call.
> Imre and Frank suggested we limit the scope of the feature from what was
> shaping up based on the work I did in May. Just this week I had another
> call with Frank about it, and I'm starting to think it's better to go
> with the reduced scope. I'd like to get your thoughts on it. Let me
> briefly describe the two sizes.
>
> SETION: Full Multi-Templating
>
> Take a look at section 10.2.2 in the PDF to get an idea of where I was
> going with the feature in its full scope. Basically, the full scope of
> the feature is to build a decently featured, but light weight CMS on top
> of JSF.
>
> Going even deeper, here is some text I wrote up recently describing the
> full scope of the feature.
>
> 8<-----------------------------
> Introduction
>
> Multi-templating enables defining a contract that states what are the
> logical areas of your application but leaves the visual styling and
> spatial arrangement of those areas areas as an implementation detail.
> If you code your application to that contract, than any multi-template
> implementing that contract can be dropped in and used.
>
> It is easier to talk about this feature after defining several roles,
> each of which describes specific kinds of actions taken by individuals
> filling that role.
>
> Multi-template Author
>
> * Responsible for the visual style of the entire web application.
>
> * Responsible for the layout and arrangement of an entire web
> application. This usually means deciding the relative location of
> the navigation menu, side-bars, bottom matter etc. This may include
> design decisions that only apply for one part of the application.
>
> * Responsible to create one or more implementations of the visual
> style defined by the Multi-template Definer.
>
> Multi-template Implementer
>
> * Provides one or more implementation of the contract defined by the
> Multi-template author.
>
> Page Author
>
> * Responsible for content that fits into the template defined by the
> Multi-template author.
>
> This feature enables the Multi-template Author to define a contract with
> the following consequences
>
> * if a Page Author follows that contract when designing their pages,
> any implementation of that contract will result in the design intent
> of the Multi-template Author being fulfilled.
>
> * If a Multi-template Implementer follows that contract when designing
> their implementation of the contract, then their multi-template
> implementation can be used in any applicaction that was written to
> that contract.
>
> Basic Q&A
>
> What is a Multi-template?
>
> A multi-template is a JSF resource library that defines (and
> optionally also implements) a contract for the visual style of a web
> application, or a portion of a web application.
>
> How do I create a Multi-template?
>
> Make a JSF 2.2 resource library with a "template.xml" file in its top
> level. This file is the contract declaration of the multi-template.
>
> * It tells the Page Author everything they need to know about how to
> write pages that conform to this Multi-template.
>
> * It tells the Multi-template Author the contract they need to
> fill so that page authors writing to the contract will get the
> desired results.
>
> How does the runtime know what Multi-templates are available?
>
> At startup, the runtime discovers the available multi-templates by
> scanning the resource libraries.
>
> How does the Page Author indicate that their pages should be influenced
> by a multi-template?
>
> With configuration in the faces-config that maps multi-templates to
> areas of the application, or by explicitly declaring the
> multi-templates to be used in the <f:view> element.
>
> 8<------------------------------------
>
> SECTION: Reduced Multi-Templating
>
> This is the scope advocated by Frank and Imre during our last conference
> call. First, recall that we've already made it so facelets are loadable
> from Resource Libraries. In fact, all facelets are now served via the
> ResourceHandler.createViewResource() method.
>
> We introduce an additional piece of metadata to the concept of a
> Resource Library. Frank calls it a "resource prefix". We provide a
> read/write property on the FacesContext for it. Thus, we have the
> notion of the currently active resource prefix.
>
> We modify the spec for ResourceHandler such that whenever a resource is
> requested, we first check if we have one that declares it supports the
> currently active resource prefix. If we do, it gets served by the
> ResourceHandler. If not, we look for one without the prefix.
>
> Care must be taken with respect to the Facelet cache.
>
> SECTION: Considerations
>
> I'm pretty convinced that we should go with the Reduced
> Multi-Templating, but I want to get your thoughts before pulling it out
> and rewriting it more simply.
>
> While it is true that one can achieve the contract re-use of the Full
> proposal with the Reduced proposal, the contract is informal, and you
> really have to take the Resource Library apart to discover the contract
> if you want to offer multiple Resource Library instances that look
> different but have the same usage contract.
>
> The JSF spec is already gigantic so adding a whole site management
> system on top of it may not be the best choice.
>
> ACTION: If you want to support the Full Multi-Templating scope, I need
> to hear from you by 17:00 EST Monday 5 November 2012. At that point,
> I'm going to start working on the Reduced scope in earnest. Of course,
> I welcome feedback on the entire spec, any feedback is welcome.
>
> If you have trouble accessing the PDF, please let me know and I'll fix
> it.
>
> Thanks,
>
> Ed
>
> --
> | edward.burns_at_oracle.com | office: +1 407 458 0017
> | homepage: | http://ridingthecrest.com/
>
> [1] http://java.net/projects/javaserverfaces-spec-public/downloads/download/JSF_2_2/spec_snapshots/javax.faces-api-2.2-SNAPSHOT-20121102-javadoc.jar