Hello Thiago,
ciao is fine, you are right!

The idea of binding prefix is interesting, I never thought of using it this way!
Thanks again,
Luca


> Sent: Saturday, April 28, 2018 at 8:55 PM
> From: "Thiago H. de Paula Figueiredo" <thiag...@gmail.com>
> To: "Tapestry users" <users@tapestry.apache.org>
> Subject: Re: Access request from tml / standard servlet api role support
>
> On Sat, Apr 28, 2018 at 7:51 AM, Luca Arzeni <l.arz...@iname.com> wrote:
> 
> > Hi,
> >
> 
> Hello, Luca! (Ciao? :D )
> 
> 
> > this is an idea, but I was hoping to have direct access to the request.
> > In tapestry3 there was a direct way to access the Visit Object, and the
> > ognl was well documented, but it seems that there is no more similar in
> > tapestry5.
> >
> 
> There isn't and that's by design. The Tapestry 5 philosophy, at least the
> internal one, is to have the least code in templates possible, so
> ressurecting Tapestry 4-'s direct access to the request object wouldn't
> make sense, IMHO. You can always create your own binding prefixes, though,
> so you can do basically everything with Tapestry expressions as long as
> you're willing to implement a binding prefix.
> 
> 
> >
> > Thank you,
> > larzeni
> >
> >
> > > Sent: Saturday, April 28, 2018 at 12:41 AM
> > > From: "pico.dev" <pico....@gmail.com>
> > > To: "Tapestry users" <users@tapestry.apache.org>
> > > Subject: Re: Access request from tml / standard servlet api role support
> > >
> > > Hi,
> > >
> > > Maybe you can implement a new conditional component that checks the role
> > > and render or not its body. Something like this:
> > >
> > > <t:isUserInRole role="ADMIN">
> > >     <a t:id="saveButton" type="button" href="#">SAVE DATA</a>
> > > </t:isuserInRole>
> > >
> > > See https://tapestry.apache.org/component-rendering.html
> > >
> > > Regards,
> > >
> > > El sáb., 28 abr. 2018 a las 0:12, Luca Arzeni (<l.arz...@iname.com>)
> > > escribió:
> > >
> > > > Hi,
> > > > I'm using tapestry5.4 with java 8.
> > > >
> > > > I am using the standard servlet API to check if a user is in role or
> > not,
> > > > to hide or show buttons, links, and so on.
> > > >
> > > > For example, I need to show a button to the user only if the user has
> > been
> > > > granted a role.
> > > >
> > > > My usual way to to this is:
> > > >
> > > > 1) create a method in the page, for example:
> > > >
> > > > @Inject
> > > > RequestGlobals m_requestGlobals;
> > > >
> > > > public boolean isUserAdmin() {
> > > >         if (m_requestGlobals == null) {
> > > >                 return false;
> > > >         }
> > > >         return m_requestGlobals.isUserInRole("ADMIN");
> > > > }
> > > >
> > > > 2) then, in the tml, check the method using a t:if component, for
> > example:
> > > >
> > > > <t:if test="userAdmin">
> > > >                 <a t:id="saveButton" type="button" href="#">SAVE
> > DATA</a>
> > > > </t:if>
> > > >
> > > > This is not so good, since I must reimplement the same method in many
> > > > pages.
> > > >
> > > > Is there any way could I access the requestGlobals directly from tml?
> > > >
> > > > My goql would be to write, directly in the tml, something like:
> > > >
> > > >
> > > > <t:if test="request.isuserInRole('ADMIN')">
> > > >         <a t:id="saveButton" type="button" href="#">SAVE DATA</a>
> > > > </t:if>
> > > >
> > > >
> > > > Is it possible to do this with tapestry5?
> > > >
> > > > Thanks in advance,
> > > > larzeni
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> > > > For additional commands, e-mail: users-h...@tapestry.apache.org
> > > >
> > > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> > For additional commands, e-mail: users-h...@tapestry.apache.org
> >
> >
> 
> 
> -- 
> Thiago
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Reply via email to