Return-Path: Delivered-To: apmail-myfaces-dev-archive@www.apache.org Received: (qmail 96176 invoked from network); 16 Aug 2006 15:04:23 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 16 Aug 2006 15:04:23 -0000 Received: (qmail 28958 invoked by uid 500); 16 Aug 2006 15:04:22 -0000 Delivered-To: apmail-myfaces-dev-archive@myfaces.apache.org Received: (qmail 28722 invoked by uid 500); 16 Aug 2006 15:04:21 -0000 Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "MyFaces Development" Delivered-To: mailing list dev@myfaces.apache.org Received: (qmail 28711 invoked by uid 99); 16 Aug 2006 15:04:21 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 Aug 2006 08:04:21 -0700 X-ASF-Spam-Status: No, hits=0.5 required=10.0 tests=DNS_FROM_RFC_ABUSE,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of cagatay.civici@gmail.com designates 64.233.162.206 as permitted sender) Received: from [64.233.162.206] (HELO nz-out-0102.google.com) (64.233.162.206) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 Aug 2006 08:04:19 -0700 Received: by nz-out-0102.google.com with SMTP id n1so122926nzf for ; Wed, 16 Aug 2006 08:03:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=LAB5HejpA7QESz4lOv54kSm56ovQ9VOq5ZpUXLmbdw0O5a0lNvXYxtKNzM/yJaNr1CWulwCRF0SZ4gJWYbE6XDLFs7poc1IVo7ZvNQe1uFLiDR8UJV7SqxVsJ7tPeu1zELziKCW/rsKs4VjVl5S15jEiW6UierYtiB+VKvQG3YA= Received: by 10.35.45.1 with SMTP id x1mr1523400pyj; Wed, 16 Aug 2006 08:03:59 -0700 (PDT) Received: by 10.35.118.9 with HTTP; Wed, 16 Aug 2006 08:03:59 -0700 (PDT) Message-ID: <8c9d4eaa0608160803v3642d27dq86701fecbcf5cc07@mail.gmail.com> Date: Wed, 16 Aug 2006 18:03:59 +0300 From: "Cagatay Civici" To: "MyFaces Development" Subject: Re: s:secure In-Reply-To: <8f985b960608160752l63e2ade1td2a884299cf33c8b@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_222408_8212667.1155740639333" References: <4AB9FAC47CFEC14C9EE1C88AC96EF76A0600E0@SBYEXCP03.ibt.ibtco.com> <5a99335f0608160718k71a3877l4726dfee864523b4@mail.gmail.com> <8f985b960608160730n77009cc5re1ed1324aa97e231@mail.gmail.com> <5a99335f0608160744p737c971ag1e566a4910386fb2@mail.gmail.com> <8f985b960608160752l63e2ade1td2a884299cf33c8b@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_222408_8212667.1155740639333 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline > > I think the real question is where to draw the line. Should we > really be maintaining a component that only works for a subset of the > cases and only saves a few characters of typing? I'd recommend that > someone who strongly feels the need for such a component start using > Facelets and implement s:secure as template that generates the > panelGroup tag :-) Typing less and reduced effort is what ROR guys are proud of nowadays:) I still think using multiple panel groups looks like a hack and we should consider not everyone is a facelets user. One user may like using EL or another user may like s:secure. In the end the whole idea is to provide out of the box features for security and reduce the amount of work and time of myfaces users that they need to enable security. Cagatay On 8/16/06, Mike Kienenberger wrote: > > On 8/16/06, Mario Ivankovits wrote: > > Having a simple secure tag will also reflect what the designer/developer > > wanted to do - just secure some components. > > > On 8/16/06, Martin Marinschek wrote: > > Then the only remaining issue is that with our suggestion, the > > rendered-attribute might contain references to both security related > > conditions _and_ other conditions - so a clear separation might not be > > provided by this. > > Can be handled by multiple panelGroups if it's required. > > > > An -tag might be more explicit > > I think the real question is where to draw the line. Should we > really be maintaining a component that only works for a subset of the > cases and only saves a few characters of typing? I'd recommend that > someone who strongly feels the need for such a component start using > Facelets and implement s:secure as template that generates the > panelGroup tag :-) > > Maintaining a "real" component is a lot of work under JSP and the > benefits of this particular component are trivial in my opinion. > > > ">http://www.mycompany.com/jsf > > secure > /WEB-INF/tags/secureComponent.xhtml > > > ------=_Part_222408_8212667.1155740639333 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I think the real question is where to draw the line.    Should we
really be maintaining a component that only works for a subset of the
cases and only saves a few characters of typing?   I'd recommend that
someone who strongly feels the need for such a component start using
Facelets and implement s:secure as template that generates the
panelGroup tag :-)

Typing less and reduced effort is what ROR guys are proud of nowadays:) I still think using multiple panel groups looks like a hack and we should consider not everyone is a facelets user.

One user may like using EL or another user may like s:secure. In the end the whole idea is to provide out of the box features for security and reduce the amount of work and time of myfaces users that they need to enable security.

Cagatay
 

On 8/16/06, Mike Kienenberger <mkienenb@gmail.com> wrote:
On 8/16/06, Mario Ivankovits <mario@ops.co.at> wrote:
> Having a simple secure tag will also reflect what the designer/developer
> wanted to do - just secure some components.


On 8/16/06, Martin Marinschek <martin.marinschek@gmail.com> wrote:
> Then the only remaining issue is that with our suggestion, the
> rendered-attribute might contain references to both security related
> conditions _and_ other conditions - so a clear separation might not be
> provided by this.

Can be handled by multiple panelGroups if it's required.


> An <s:secure/>-tag might be more explicit

I think the real question is where to draw the line.    Should we
really be maintaining a component that only works for a subset of the
cases and only saves a few characters of typing?   I'd recommend that
someone who strongly feels the need for such a component start using
Facelets and implement s:secure as template that generates the
panelGroup tag :-)

Maintaining a "real" component is a lot of work under JSP and the
benefits of this particular component are trivial in my opinion.

<facelet-taglib>
   <namespace>">http://www.mycompany.com/jsf</namespace>
   <tag>
   <tag-name>secure</tag-name>
   <source>/WEB-INF/tags/secureComponent.xhtml</source>
   </tag>
</facelet-taglib>

------=_Part_222408_8212667.1155740639333--