Return-Path: 
 <jetspeed-dev-return-33437-apmail-portals-jetspeed-dev-archive=portals.apache.org@portals.apache.org>
Delivered-To: apmail-portals-jetspeed-dev-archive@www.apache.org
Received: (qmail 83367 invoked from network); 18 Feb 2009 16:21:32 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 18 Feb 2009 16:21:32 -0000
Received: (qmail 7127 invoked by uid 500); 18 Feb 2009 16:21:30 -0000
Delivered-To: apmail-portals-jetspeed-dev-archive@portals.apache.org
Received: (qmail 7103 invoked by uid 500); 18 Feb 2009 16:21:30 -0000
Mailing-List: contact jetspeed-dev-help@portals.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:jetspeed-dev-help@portals.apache.org>
List-Unsubscribe: <mailto:jetspeed-dev-unsubscribe@portals.apache.org>
List-Post: <mailto:jetspeed-dev@portals.apache.org>
List-Id: <jetspeed-dev.portals.apache.org>
Reply-To: "Jetspeed Developers List" <jetspeed-dev@portals.apache.org>
Delivered-To: mailing list jetspeed-dev@portals.apache.org
Received: (qmail 7069 invoked by uid 99); 18 Feb 2009 16:21:30 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 18 Feb 2009 08:21:30 -0800
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: local policy)
Received: from [216.200.145.36] (HELO omta0110.mta.everyone.net)
 (216.200.145.36)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 18 Feb 2009 16:21:22 +0000
Received: from dm07.mta.everyone.net (sj1-slb03-gw2 [172.16.1.96])
	by omta0110.mta.everyone.net (Postfix) with ESMTP id CC0CA5E9A14
	for <jetspeed-dev@portals.apache.org>; Wed, 18 Feb 2009 08:29:19 -0800 (PST)
X-Eon-Dm: dm07
Received: by dm07.mta.everyone.net (EON-AUTHRELAY2 - 426dd405) id
 dm07.4995200c.1ed25c
	for <jetspeed-dev@portals.apache.org>; Wed, 18 Feb 2009 08:14:13 -0800
X-Eon-Sig: AQLYMZZJnDPVRkFEiwIAAAAB,a25a4d90b82149905e8c0f2dc16722c5
Message-ID: <499C33CF.2070303@wispertel.net>
Date: Wed, 18 Feb 2009 09:14:07 -0700
From: Randy Watler <watler@wispertel.net>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Jetspeed Developers List <jetspeed-dev@portals.apache.org>
Subject: Re: Adding Required Spring Categories Metadata for Filtering
References: <499C1B9D.4010904@wispertel.net> <499C2BA5.50407@douma.nu>
In-Reply-To: <499C2BA5.50407@douma.nu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org

Ate,

Thanks for the reply. I am still pondering this, so I am not sure I am 
going this route. If I do, I will follow your suggestions below.

Would you have any objections to using a separate meta tag key for 
required, (and possibly inverse), categories? I understand the use of a 
'-' and '+' in CSV lists is a pattern in Spring, but unless we start 
writing full predicate expressions, the syntax is going to be obtuse for 
the layman. Do you think something like this is more clear or more 
confusing?

<meta key="j2:requires" value="ojb"/>
<meta key="j2:cat" value="dbPageMangler"/>
<meta key="j2:alias" value"..."/>

In fact, perhaps this is even better:

<meta key="j2:requires" value="ojb"/>
<meta key="j2:supports" value="dbPageMangler"/>
<meta key="j2:alias" value"..."/>

That way I could also support this syntax in parallel:

<meta key="j2:cat" value="dbPageMangler,+ojb"/>
<meta key="j2:alias" value"..."/>

Thoughts?

Randy

Ate Douma wrote:
> Hi Randy,
>
> See inline comments below.
>
> Randy Watler wrote:
>> Gang,
>>
>> I have been pondering how to add a switch type flag to be used to 
>> select cross component technology implementations within the Spring 
>> configurations for J2. I am pondering categories like 'ojb' and 
>> 'jpa'. To be honest, I really am not convinced that filter/categories 
>> is the greatest solution, but I am trying to work with it.
>>
>> The filtering logic seems to be strictly an 'OR' operation. In other 
>> words, if any category defined in the meta data matches the current 
>> category set, the bean is included. Selecting cross concerns like 
>> 'ojb' or 'jpa' might be easier to specify as an 'AND' operation. 
>> Basically, I want to say something like: "use this bean only if a 
>> specific category is defined" in addition to the existing categories 
>> logic.
>>
>> I am doubling down on the complexity for sure, but I am wondering if 
>> this approach would have any objectors? Perhaps it is already 
>> implemented? Just checking first before I go down the path. All 
>> feedback welcome.
> You're assessment is correct: *currently* filtering only works using 
> 'OR' operations.
> Adding 'AND' (and likely '!') operations definitely would be very 
> helpful but so far we haven't had time (nor real need) to add that.
> Doing so probably shouldn't be too difficult to do.
> The current 'OR' handling is handled in the 
> JetspeedBeanDefinitionFilter.match() method, and it simply parses the 
> list of categories specified for a bean and see if any of those match 
> the configured categories.
> Adding 'AND' and '!' logic probably can be add very easily by checking 
> if a specified category starts with a '+' (AND) or '-' (NOT) and then 
> deal with it accordingly.
>
> I surely see no objections to adding such functionality!
>
> Regards,
>
> Ate
>>
>> Randy
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
>> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org