Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] Newbie question on inter-type member declarations 
Hello,


Thanks again for your feedback, Wes!  A little example from our code may
clarify our needs:

public class Project {

    // ...

    private double budget;
    public double getBudget() {
        return budget;
    }
    public void setBudget(double budget) {
        this.budget = budget;
    }

    public String getBudgetAsString() {
        return NumberUtil.formatDoubleToString(budget);
    }
    public void setBudgetAsString(String budget) {
        this.budget = NumberUtil.parseDouble(budget);
    }

    // ...

}

Note that both properties operate on the same member variable. Now, in one
of the JSPs we will have something like this:

<html:form action="/updateProject" styleId="ProjectForm">
    ...
    <html:text property="project.budgetAsString" />
    ...
</html:form>


The html:text tag causes an html text input field to be generated in the
html form. The field will be initialized with the value from the budget
member variable, formatted according to our preferences. If the user
modifies the value and hits submit then the new value will be written back
to the budget member variable. All this is handled automatically by the
Struts framework using reflection to obtain the correct get/set methods for
the budgetAsString property.

Note that it's not just a matter of presenting the value but also of
changing it. Thus it's crucial that there is an actual *property* for Struts
to access. And hence none of the proposed solutions will work. At least I
think so. (As mentioned before - I'm a newbie :-).

The "property pattern" described above has showed very convenient on our
project, but of course there are som disadvantages:
- The domain code is cluttered up with presentation code, which makes the
domain code harder to read.
- We need to write and maintain more code.

You win some, you lose some. And in this case I feel we win more than we
lose. But, if we could have this pattern enforced by a single aspect we
would win even more and lose nothing. It would be a clean separation between
domain and presentation and the coding effort would be zero...

Best regards,


Are Meisfjord

----- Original Message ----- 
From: "Wes Isberg" <wes@xxxxxxxxxxxxxx>
To: <aspectj-users@xxxxxxxxxxx>
Sent: Tuesday, August 10, 2004 1:34 PM
Subject: Re: [aspectj-users] Newbie question on inter-type member
declarations


>
> > can you explain why you dont like any of those solutions?
>
> sure...
>
> > > You might get as much convenience from a utility - variants:
> > >
> > >    String.valueOf(x)
> > >    Renderer.render(int x)
> > >    getRenderer(y).render(y.x, "fieldname")
>
> Rendering is a function of
> - type-rendered-to
> - type-rendered-from
> - semantics of the field
> - context of display
> - also caching?
> so a complete utility solution would be highly parameterized
> and know a lot about the other components.  I typically find
> that these rendering decisions should be made at the view layer
> (by the interface designer) rather than having the domain
> programmer make those decisions; aside from having the expert
> decide, often the view layer has more natural support for
> this function.  Just a bias.
>
> > > AspectJ could parameterize around the field name for lazy
> > initialization:
>
> The usefulness of the AspectJ solutions depends on how crosscutting
> they are (if not, then why use aspects?) and the overhead/cost.
>
> This next one has reflective overhead, both to access the value and
> likely to introspect the type to figure out how to handle it.
> (Another option would register renderers for each field-context
> pair.)  So the extent of crosscutting depends more on the logic
> in the commented part being able to handle all the fields picked
> out.  There's no guarantee of that.  And if, or since, the field
> name is used as a key, a rename-field refactoring would break a
> lot of code.  To my mind, a new subclass shouldn't break the aspect,
> but it might here.
>
> > >    String around(Item item) : get(String *AsString) && target(Item) {
> > >       String result = proceed(item);
> > >       if (result == null) {
> > >          // reflectively set field, based on utility call, keyed off
> > > field signature
> > >       }
> > >       return result;
> > >    }
> > >
>
> This next one has the same problem in the default case.  It also relies
> on a technique (of using precedence to resolve ITMD collisions)
> that is unfamiliar to most programmers.  It forces the developer
> to "override" on a per-type basis, so s/he has to sign up for
> handling other fields and other types.  However, I can imagine
> using the call join point to gather information about the caller
> as well, to satisfy per-caller rendering requirements.
>
> > > Or perhaps for each domain element viewable on a web page:
> > >
> > >    interface IWeb {  String fieldAsString(String fieldName); }
> > >    aspect ImplementingIWeb {
> > >        declare parents {domainClasses} implement IWeb;
> > >        public String IWeb.fieldAsString(String fieldName) {
> > >             // default, reflective implementation
> > >        }
> > >    }
> > >
> > >    /** override default implementation for Item */
> > >    aspect ImplementingIWebForItem {
> > >        declare precedence ImplementingIWebForItem, ImplementingIWeb;
> > >        public String Item.fieldAsString(String fieldName) {
> > >             // custom Item implementation
> > >        }
> > >    }
> > >
> > > (I personally don't like any of these options, but they might be
> > worth
> > > considering.)
> > >
> > > Hope this helps -
> > > Wes
> > >
> > >
> > >
> > >     ------------Original Message------------
> > >     From: "Are Meisfjord" <are@xxxxxxxxxxxxx>
> > >     To: aspectj-users@xxxxxxxxxxx
> > >     Date: Mon, Aug-9-2004 2:10 AM
> > >     Subject: [aspectj-users] Newbie question on inter-type member
> > >     declarations
> > >     Hello!
> > >
> > >
> > >     I'm wondering if it's possible in AspectJ to add inter-type
> > member
> > >     declarations based on pointcuts? A little example to illustrate
> > what
> > >     I mean:
> > >
> > >     We have a web application using Struts. For convenience we
> > >     have introduced a naming convention requiring certain properties
> > in
> > >     our domain model classes to have extra ...AsString properties
> > that
> > >     formats the properties correctly for presentation in web pages
> > >     (using Struts taglibs). So if we have a property 'salary' in the
> > >     Employee class we will also have a property 'salaryAsString' that
> > >     returns the salary (originally a double) as a string with
> > thousand
> > >     separators and two decimal precision.
> > >
> > >     Is it possible to enforce this convention throughout the
> > application
> > >     with an aspect? Of course, We could list each ...AsString method
> > as
> > >     an inter-type member declaration in the aspect, but that won't be
> > >     much of an improvement wrt programming effort. It would be much
> > >     better if we could make a pointcut selecting all get and set
> > methods
> > >     of interest and then apply an advice on them that added the extra
> > >     methods...
> > >
> > >     Regards,
> > >
> > >
> > >     Are Meisfjord
> > >
> >
> > _______________________________________________
> > aspectj-users mailing list
> > aspectj-users@xxxxxxxxxxx
> > http://dev.eclipse.org/mailman/listinfo/aspectj-users
> >
>
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-users
>

Back to the top