Not ideal, for sure. I think part B of my proposal is much better --
an application.page file that has normal page-file semantics to
inject/add whatever is needed across all pages:
application.page file:
<page-specification>
<inject property="fooService" object="service:mymodule.fooService"/>
</page-specification>
Then any page that wanted the FooService could just do:
public abstract MyPage extends BasePage {
[...]
public abstract FooService getFooService();
[...]
}
The same would apply for properties/etc. Seems useful, and the use
could be checked at compile time.
Think I might have a go at this. Never really looked at the bowels of
tap, so this is all new to me. Anyone have any pointers of where to
start?
-Mike
On 4/10/06, Sam Gendler <[EMAIL PROTECTED]> wrote:
> > @Tap Team:
> > How difficult would it be to add the ability to either:
> > A) declare services/aso's as 'global' (or some better label), such
> > that every page gets it injected?
>
> But bear in mind that anything that would be injected 'blind' by the
> framework would not be visible within the public interface of a class.
> Meaning you would lose all compile time checking of parameter and
> return types. You would be forced to access all your global
> properties via PropertyUtils/reflection since your actual Page classes
> wouldn't have methods to access those properties. Yes, it would be
> doable, but I'm not sure that's a trade-off many of us would want to
> make.
>
> That said, in every company I've ever worked for, the only sure-fire
> way to get the product management team to consider a feature that the
> engineers thought would be cool but PM were oblivious to, was to just
> implement it and then show them how useful it was. So if you really
> want this, you might make a stab at implementing it yourself. If you
> hand the Tap team a finished feature which is 100% backwards
> compatible with older code AND useful, odds are pretty good it will
> make it into a release, I'd imagine.
>
> --sam
>
>
> > B) Come up with an application.page file that has
> > property/service/component/script/etc declarations that are available
> > on ALL pages in the app (perhaps limited by packaging or something).
> >
> > If you guys think it's do-able, several of us would appreciate it.
> > Let me know and I'll add the request to JIRA.
> >
> > -Mike
> >
> > On 4/10/06, Sam Gendler <[EMAIL PROTECTED]> wrote:
> > > How about @InjectObject("spring:someBean") to get whatever resources
> > > you want from spring. And an @InitialValue() annotation to initialize
> > > things that don't come from spring. I haven't tried it, but perhaps
> > > @InitialValue("new Logger(this.getClass().getName())") (or whatever
> > > the appropriate ognl syntax would be) on a log property. The problem
> > > with doing a log object in the base class, of course, is that all log
> > > messages would appear to be from the base class. You really need a
> > > separate logger instance in your base class and subclass in order to
> > > differentiate exactly where the log messages are truly coming from.
> > >
> > > --sam
> > >
> > >
> > > On 4/9/06, Mark <[EMAIL PROTECTED]> wrote:
> > > > Hi Pedro,
> > > >
> > > > this would work, but now you have the LogFactory reference hard-coded.
> > > >
> > > > I am trying to be completely independent and just inject everything.
> > > >
> > > > I found something on the Spring site that is extending BaseEngine, in
> > > > order to add a hook to the application-context into the IEngine
> > > > Implementation:
> > > > http://static.springframework.org/spring/docs/1.2.x/reference/webintegration.html#view-tapestry-exposeappctx
> > > >
> > > > It puts the hook into the Global object. Since this is designed for T3,
> > > > I guess T4 could use an application-scope ApplicationStateObject to do
> > > > this.
> > > > It could be created in the HiveMind module deployment descriptor:
> > > > <contribution configuration-id="tapestry.state.ApplicationObjects">
> > > > <state-object name="logFactory" scope="application">
> > > > <create-instance class="some.new.logFactory"/>
> > > > </state-object>
> > > > </contribution>
> > > >
> > > > Then it could be injected in the .page file:
> > > > <inject name="registration" type="state" object="logFactory"/>
> > > >
> > > > The question is just: how can I make the BasePageImplementation initiate
> > > > the injection, so that I do not have to do it in each .page file any
> > > > more:
> > > >
> > > > public class BasePageImplementation extends BasePage {
> > > > private Log logger;
> > > >
> > > > public BasePageImplementation() {
> > > > // Since all page classes are inherited Tapestry generated
> > > > classes
> > > > // we use the superclass to initialize the log
> > > > logger = <getHivemindApplicationObject("logFactory")> // <!---
> > > > this is what I am missing! How can I do this?
> > > > }
> > > >
> > > > /**
> > > > * @return Returns the logger.
> > > > */
> > > > public Log getLogger() {
> > > > return logger;
> > > > }
> > > > }
> > > >
> > > >
> > > > This way, if want to switch the Log implementation, I can switch the
> > > > LogFactory by just simply changing the hivemind module decriptor.
> > > > So I am just missing the one last part of the puzzle: How can I access
> > > > all the stuff that is defined in the Hivemind configurations from within
> > > > the java objects directly, rather than from the .page files?
> > > >
> > > > Thanks,
> > > >
> > > > MARK
> > > >
> > > >
> > > >
> > > >
> > > > Pedro Viegas wrote:
> > > > > Why not something like...
> > > > >
> > > > > public class BasePageImplementation extends BasePage {
> > > > > private Log logger;
> > > > >
> > > > > public BasePageImplementation() {
> > > > > // Since all page classes are inherited Tapestry generated
> > > > > classes
> > > > > // we use the superclass to initialize the log
> > > > > logger = LogFactory.getLog(this.getClass().getSuperclass());
> > > > > }
> > > > >
> > > > > /**
> > > > > * @return Returns the logger.
> > > > > */
> > > > > public Log getLogger() {
> > > > > return logger;
> > > > > }
> > > > > }
> > > > >
> > > > > Works for me. :-)
> > > > >
> > > > >
> > > > > On 4/9/06, Mark <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > >> Yes, that's what I have done.
> > > > >> But still - let's assume I have something like
> > > > >>
> > > > >> public abstract class LogAwareBasePage extends BasePage implements
> > > > >> PageBeginRenderListener {
> > > > >> Log log;
> > > > >> public void setLog(Log log) { ... }
> > > > >> public Log getLog() { ... }
> > > > >> }
> > > > >>
> > > > >> I still don't have the log property initialized.
> > > > >> Sure, I could do this:
> > > > >>
> > > > >> public abstract class LogAwareBasePage extends BasePage implements
> > > > >> PageBeginRenderListener {
> > > > >> Log log = new SomeClassThatImplementsLog("param1", "param2",
> > > > >> ...);
> > > > >> public void setLog(Log log) { ... }
> > > > >> public Log getLog() { ... }
> > > > >> }
> > > > >>
> > > > >> But this is not runtime-configurable...
> > > > >>
> > > > >>
> > > > >> Or I could do it in my .page file:
> > > > >>
> > > > >> <property name="log">ognl:Some OGNL expression</property>
> > > > >>
> > > > >> So I could plug it in the .page files, but that would have to be
> > > > >> done in
> > > > >> each .page file again and again. So if I want to switch the Log
> > > > >> implementation, at least I don't have to modify my java code, but I
> > > > >> will
> > > > >> have to change every single .page file.
> > > > >>
> > > > >> So I am hoping that I could somehow use Hivemind instead to configure
> > > > >> the injection of the Log implementation, but I don't know how.
> > > > >>
> > > > >>
> > > > >> Also, as an additional challenge: My application architecture is
> > > > >> using
> > > > >> Spring for the configuration and property injection on all the other
> > > > >> layers, so ideally, I would like to use Spring to initialize the log
> > > > >> property, so that I do not have to define all the beans twice (once
> > > > >> in
> > > > >> Spring and once in Hivemind). Maybe the bridge from the
> > > > >> tapestry-spring
> > > > >> project can be used for that???
> > > > >>
> > > > >> Thanks for the help,
> > > > >>
> > > > >> MARK
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >> Sam Gendler wrote:
> > > > >>
> > > > >>> Define a MyBasePage which has all the properties you want, and then
> > > > >>> make all your pages inherit from that.
> > > > >>>
> > > > >>> --sam
> > > > >>>
> > > > >>>
> > > > >>> On 4/9/06, Mark <[EMAIL PROTECTED]> wrote:
> > > > >>>
> > > > >>>
> > > > >>>> Hello,
> > > > >>>>
> > > > >>>> is there a way to "globally" inject certain properties in a large
> > > > >>>>
> > > > >> number
> > > > >>
> > > > >>>> of pages, without having to do it in each page specification file?
> > > > >>>> For example, I expect all my pages to have a "log" Property which
> > > > >>>> is an
> > > > >>>> implementation of the commons-logging Log interface.
> > > > >>>> But I want to plug the particular implementation of the Log
> > > > >>>> interface
> > > > >>>> using injection at runtime, just like all the other page
> > > > >>>> properties are
> > > > >>>> plugged at runtime based on the .page specification file as well.
> > > > >>>> However, I don't want to have to include the same property
> > > > >>>> definition
> > > > >>>>
> > > > >> in
> > > > >>
> > > > >>>> every single page-descriptor, since it is not very well
> > > > >>>> maintainable.
> > > > >>>> Imagine I have 100 pages and now want to change the implementation
> > > > >>>> of
> > > > >>>> the Log interface - I have to change 100 different .page files.
> > > > >>>>
> > > > >>>> So is there a way to do this in a better way?
> > > > >>>>
> > > > >>>> Thanks,
> > > > >>>>
> > > > >>>> MARK
> > > > >>>>
> > > > >>>> ---------------------------------------------------------------------
> > > > >>>> 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]
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >> ---------------------------------------------------------------------
> > > > >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > >> For additional commands, e-mail: [EMAIL PROTECTED]
> > > > >>
> > > > >>
> > > > >>
> > > > >
> > > > >
> > > > > --
> > > > > Pedro Viegas
> > > > >
> > > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > 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]
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
