Hi.

You /can/ set up any folders you want to declare as resources; and per-folder, 
turn filtering on or off. Each folder can have includes and excludes. 
Filtering is disabled by default.

You could move all your message bundles out of this directory and into some 
new one, and enable filtering; which is really a strange thought. A more 
logical thought is to invent a new such directory for the templates. Would 
Tap have any issue with that? And, would "src/main/html" make any sense? Or 
is there some other "language" name to use for Tap instead of html? 
I.e.: "src/main/tapestry?".

The truly wrong way is to redundantly declare the overlapping resource 
directory; since filtering is per-directory:

    <resources>
      <resource>
        <directory>src/main/resources</directory>
        <filtering>true</filtering>
        <excludes>
          <exclude>**/*.html</exclude>
        </excludes>
      </resource>
      <resource>
        <directory>src/main/resources</directory>
        <filtering>false</filtering>
        <includes>
          <include>**/*.html</include>
        </includes>
      </resource>
    </resources>

Which does work, but just puts development where administration should go.

My personal observation: A Tapestry-specific resource directory sounds 
reasonable. And in fact, how do you get assets in T5? Is there any need for 
them to appear in src/main/webapp? If not, they might be perfectly at home 
also in that Tapestry resource directory, which might make them sort of 
neatly arranged: it might get odd if some had to appear in webapp/ and others 
in resources/. And I'm still not completely settled with locating templates 
inside WEB-INF: it has become a sort of dumping ground -- the simple case of 
seeing app.properties next to templates makes it disconcerting! Plus they are 
separated from the component templates.

One strange aspect is that technically, a T5 app is probably not a WebApp. So 
the webapp archetype is putting needless constraints around things. Or, T5 is 
just now up a layer on top of the webapp, and implementation artifacts are 
being exposed to us, where they should no longer be.

Do you have any suggestions? --- I can guarantee you they're better than 
mine...

Thanks for replying.

Ciao!
-Steev Coco.


On Tue July 3 2007 4:23:03 pm you wrote:
> Can't you set up multiple resource folders, some filtered, some not?
>
> On 7/2/07, Steven Coco <[EMAIL PROTECTED]> wrote:
> > Hi.
> >
> > Has there been discussion about the fact that Maven can filter resources,
> > located in src/main/resources, and if templates are placed there, then
> > Maven
> > may munge expansions intended for Tapestry, or maybe also vice-versa?
> >
> > The tutorial says templates should be placed here. I have been using
> > WEB-INF,
> > mainly because application reloading during development is instant this
> > way,
> > but when they are in the resources directory, it doesn't pick up changes.
> > And
> > other than that there seems to be no difference. But I can easily see a
> > problem with resource filtering.
> >
> > In light of this comment, what then is the fate for component templates?
> > I think they currently are required to appear in src/main/resources, so
> > there
> > may be real problems.
> >
> > You can configure excludes in Maven's resource plugin; but that may not
> > be a
> > guaranteed solution: you may have properties bundles for components that
> > do
> > need to be filtered by Maven, and the task of configuring those excludes
> > is
> > not straightforward, and things may get too onerous to be practical.
> >
> > The potential for clashes should be a pretty big concern I'd think; since
> > resource filtering is common, and once a project scales up with many
> > pages and components, the odds of a Tapestry expansion matching a Maven
> > one will be
> > high.
> >
> > Any comments on this?
> >
> > Ciao!
> > Steev Coco.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to