Re: [macker-user] Evaluation questions

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Looks great.

Man, I really wish I had time / funding to work on another version of  
Macker. A few new features could make this much simpler.

P

On Sep 16, 2008, at 10:34 AM, Pablo Mosquera Saenz wrote:

> The solution you gave me for the Exception works great. I apply it  
> to my interfaces
>
> <access-rule severity="error">
>             <message>La capa SERVICE sólo pueden lanzar excepciones  
> de tipo ServiceException</message>
>             <deny>
>                 <from pattern="serviceInterface" />
>                 <to pattern="exception" />
>                 <allow>
>                     <to>
>                         <include class="$ 
> {base}.framework.core.util.exception.ServiceException"/>
>                     </to>
>                 </allow>
>             </deny>
>         </access-rule>
>
>         <access-rule severity="error">
>             <message>La capa DAO sólo pueden lanzar excepciones de  
> tipo DataBaseException</message>
>             <deny>
>                 <from pattern="daoInterface" />
>                 <to pattern="exception" />
>                 <allow>
>                     <to>
>                         <include class="$ 
> {base}.framework.core.util.exception.DataBaseException"/>
>                     </to>
>                 </allow>
>             </deny>
>         </access-rule>
>
>
> Thanks
>
> 2008/9/16 Paul Cantrell <can...@po...>
> Yes, your rules file is very good! You definitely have the right idea.
>
>> All classes of type *DaoImpl must extend BaseDao and implement  
>> their own interface (FooDaoImpl must implement FooDao for example)
>
> You can do this, though it's a bit messy. In order to say "X must be  
> true for all Y," set up an access rule that denies references from Y  
> minus X to java.lang.Object. So your case would look like this:
>
>     <!-- warning: untested code! -->
>     <foreach var="dao" class="(**Dao)Impl">
>         <pattern name="dao-impl" class="${dao}Impl"/>
>
>         <access-rule>
>             <message>DaoImpls must extend BaseDao</message>
>             <deny>
>                 <from>
>                     <include pattern="dao-impl"/>
>                     <exclude filter="subtype-of"  
> class="foo.bar.BaseDao"/>
>                 </from>
>                 <to class="java.lang.Object"/>
>             </deny>
>         </access-rule>
>
>         <access-rule>
>             <message>DaoImpls must implement the corresponding  
> interface</message>
>             <deny>
>                 <from>
>                     <include pattern="dao-impl"/>
>                     <exclude filter="subtype-of" class="${dao}"/>
>                 </from>
>                 <to class="java.lang.Object"/>
>             </deny>
>         </access-rule>
>     </foreach>
>
> If the FooDao interface and FooDaoImpl are in different packages,  
> you'll need to capture the class and package name separately in the  
> foreach. Let me know if you need help w/that.
>
> Cheers,
>
>
> Paul
>
>
> On Sep 15, 2008, at 7:00 AM, Pablo Mosquera Saenz wrote:
>
>> Hi Paul, I want some advice for my rules definition. Could you  
>> please tell me if Im going in the right way?
>>
>> I want to define some rules:
>>
>> Base patterns
>>
>>          <var name="base" value="es.xunta.cptopt" />
>>
>>         <pattern name="java-api" class="java*.**" />
>>         <pattern name="exception" class="**Exception" />
>>         <pattern name="service-layer" class="$ 
>> {base}.**.service.**" />
>>         <pattern name="dto-layer" class="${base}.**.dto.**" />
>>         <pattern name="pojo-layer" class="${base}.**.pojo.**" />
>>         <pattern name="dao-layer" class="${base}.**.dao.**" />
>>         <pattern name="bundle-layer" class="${base}.**.bundle.**" />
>>         <pattern name="hibernate-layer" class="org.hibernate.**" />
>>         <pattern name="bb-layer" class="$ 
>> {base}.**.view.impl.**.*BB*" />
>>
>>         <pattern name="bbData" class="$ 
>> {base}.**.view.impl.**.*Data" />
>>
>>         <pattern name="daoInterface" pattern="dao-layer">
>>             <exclude class="${base}.**.dao.impl"/>
>>         </pattern>
>>         <pattern name="serviceInterface" pattern="service-layer">
>>             <exclude class="${base}.**.service.impl"/>
>>         </pattern>
>>         <pattern name="dtoInterface" pattern="dto-layer">
>>             <exclude class="${base}.**.dto.impl"/>
>>         </pattern>
>>
>>
>> Only DAO and POJO layer classes can access to hibernate layer classes
>>
>> <access-rule severity="error">
>>             <message>Solo la capa DAO y POJO pueden acceder a la  
>> capa HIBERNATE</message>
>>             <deny>
>>                 <to pattern="hibernate-layer" />
>>                 <allow>
>>                     <from pattern="dao-layer" />
>>                     <from pattern="pojo-layer" />
>>                 </allow>
>>             </deny>
>>         </access-rule>
>>
>> All classes of type *DaoImpl must extend BaseDao and implement  
>> their own interface (FooDaoImpl must implement FooDao for example)
>>
>> Don´t know how this can be reached
>>
>> All SERVICE layer classes must access DAO layer classes through DAO  
>> interfaces
>>
>> Can it be done this?
>>
>>
>> Thanks
>>
>>
>> 2008/9/8 Paul Cantrell <can...@po...>
>> These are possible:
>>
>>> all classes of type *DaoImpl must extend BaseDao and implement  
>>> their own interface (FooDaoImpl must implement FooDao for example)
>>> all classes of type *ServiceImpl cant use *POJO classes
>>> All classes of type *ServiceImpl can use *Dao but not *DaoImpl
>>
>> These are not quite possible:
>>
>>> all methods defined in *Service and *ServiceImpl can only throw  
>>> ServiceException
>>> all methods defined in *Dao and *DaoImpl can only throw  
>>> DataBaseException
>>
>>
>> The current version of Macker cannot distinguish between "throws"  
>> and "uses." So you could write rules of the form "all methods in  
>> *Dao and *DaoImpl cannot use any subclass of Exception except  
>> DataBaseException," but that would cover throwing and catching.
>>
>> You can still probably do what you want. In an interface, "uses"  
>> can only mean "throws." If you made that rule apply only to the  
>> interfaces, it would prevent any API methods from throwing  
>> exceptions other than DataBaseException — and the implementing  
>> classes could therefore also only throw those exceptions.
>>
>> Cheers,
>>
>> Paul
>>
>>
>> On Sep 5, 2008, at 6:02 AM, Pablo Mosquera Saenz wrote:
>>
>>>
>>> Hi, Im looking for a tool to make that gives me some way to  
>>> evaluate my architecture.
>>>
>>> The kind of rules I want to define are:
>>>
>>> all classes of type *DaoImpl must extend BaseDao and implement  
>>> their own interface (FooDaoImpl must implement FooDao for example)
>>> all classes of type *ServiceImpl cant use *POJO classes
>>> All classes of type *ServiceImpl can use *Dao but not *DaoImpl
>>> all methods defined in *Service and *ServiceImpl can only throw  
>>> ServiceException
>>> all methods defined in *Dao and *DaoImpl can only throw  
>>> DataBaseException
>>>
>>> Can macker do this?
>>>
>>> Thanks in advance
>>>
>>> -------------------------------------------------------------------------
>>> This SF.Net email is sponsored by the Moblin Your Move Developer's  
>>> challenge
>>> Build the coolest Linux based applications with Moblin SDK & win  
>>> great prizes
>>> Grand prize is a trip for two to an Open Source event anywhere in  
>>> the world
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/_______________________________________________
>>> Macker-user mailing list
>>> Mac...@li...
>>> https://lists.sourceforge.net/lists/listinfo/macker-user
>>>
>>> Macker home page: http://innig.net/macker/
>>
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's  
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win  
>> great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in  
>> the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Macker-user mailing list
>> Mac...@li...
>> https://lists.sourceforge.net/lists/listinfo/macker-user
>>
>> Macker home page: http://innig.net/macker/
>>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Macker-user mailing list
> Mac...@li...
> https://lists.sourceforge.net/lists/listinfo/macker-user
>
> Macker home page: http://innig.net/macker/
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/_______________________________________________
> Macker-user mailing list
> Mac...@li...
> https://lists.sourceforge.net/lists/listinfo/macker-user
>
> Macker home page: http://innig.net/macker/