What we really need is the ability to "autowire" services into our components/pages. Maybe we should set something up that does that? So, if a page has a setPersonDao() method, it would automatically have the proxy for the service that implements the PersonDao interface injected into it. I can look into this. It shouldn't be that difficult.
-----Original Message----- From: Mark [mailto:[EMAIL PROTECTED] Sent: Saturday, April 22, 2006 11:39 AM To: Tapestry users Subject: Re: What to do if annotations are not available? Hi Raul, thanks for the response. Inject doesn't scale because you need to do it in every single .page file. If you have a large application, you have lots of those. I have not a lot of experience but I think you can even have many pages that do not require .page files, so all of those now need to have one as well. Now imagine you want to add a new property to your VlibPage class. Now you need to run through all of the .page files again and put the new inject tag in everywhere. I'm not sure if I understand your 3rd option. If I have a custom service, I still need to use either 1. or 2. to inject the service into the page, don't I? I had an idea last night, but don't know if it is viable: - Create a VlibBasePageComponent that handles all that stuff, inject everything into the component via .jwc file - have my VlibPage implement PageAttachListener.pageAttached(). - In pageAttached() call "getNestedComponent()" to access the component and then get all the injected stuff from there. The advantage would be that all the services, beans, etc can be injected into the component, which means I only need to add them into one .jwc file rather than all .page files. Not sure if I still need to inject the component itself into each .page file, but even if I do - at least adding new services or beans can be done in the .jwc once. 2 questions regarding this idea: 1. Would it work at all? 2. Will it work for high-traffic applications, meaning be thread-save, so that one user does not end up with properties that came from some other user's session... Thanks, MARK Raul Raja wrote: > Why <inject/> doesn't scale? > As far as I know there are three ways to access your registry ASO's > and services: > > 1. annotations > 2. <inject> > 3. Creating a custom engine service and injecting the object via > setter based dependency using their interfaces as parameters for the > setter, which in my opinion is even a heavier and a more complicated > solution. > > Are there other ways? > > best regards. > > Raul Raja. > > Mark wrote: >> Hello everybody, >> >> attached below is an excerpt of the code from the VLib sample project >> - the VlibPage Class to be more exact. >> I assume this is the BasePage subclass that is used for most (if not >> all) pages of the Vlib application. >> It uses annotations to access all the required beans, objects and >> services that are defined in Hivemind. >> >> How can I get to those objects and services if I use JDK 1.4 and do >> not have annotations? >> Please don't say "use <Inject> in the .page files" - I know that, but >> that doesn't scale at all... There has to be some better way, no?! >> >> Thanks a lot for your help! >> >> MARK >> >> >> ==================================================== >> public abstract class VlibPage extends BasePage implements >> IErrorProperty, IMessageProperty, >> PageValidateListener, OperationsUser >> { >> @Bean(VirtualLibraryDelegate.class) >> public abstract IValidationDelegate getValidationDelegate(); >> >> @InjectState("visit") >> public abstract Visit getVisitState(); >> >> @InjectStateFlag("visit") >> public abstract boolean getVisitStateExists(); >> >> @InjectPage("Login") >> public abstract Login getLogin(); >> >> @InjectMeta("anonymous-access") >> public abstract boolean getAllowAnonymousAccess(); >> >> @InjectMeta("admin-page") >> public abstract boolean isAdminPage(); >> >> @InjectObject("service:vlib.ModelSource") >> public abstract ModelSource getModelSource(); >> >> >> ==================================================== >> >> --------------------------------------------------------------------- >> 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]
