[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aspectj-dev] Aspect for AspectJ Library: Transparent Usage ofPreferences
|
Hi, Wes,
Thank you for the comments.
The aspect is reusable, but it assumes the design convention, that
preference container classes are not used for other purposes than just
listing the properties. The methods, which you propose would allow to
extract preferences from all kind of classes, but at the cost of a bit more
coding, which I try to minimize. I think both approaches are possible. I
think maybe the combination of the both methods would work best: global
properties could be specified in the container classes, while private
properties of classes can be declared directly within the class and marked
as preferences using annotations.
Could you tell what problems do you see with the static field
initialization?
Vaidas
----- Original Message -----
From: "Wes Isberg" <wes@xxxxxxxxxxxxxx>
To: "AspectJ developer discussions" <aspectj-dev@xxxxxxxxxxx>
Sent: Saturday, May 07, 2005 1:15 PM
Subject: Re: [aspectj-dev] Aspect for AspectJ Library: Transparent Usage
ofPreferences
Thank you for the proposed aspect.
It is very hard to write a reusable aspect. In this case, you advise
all fields in all subtypes as if they all had preferences. And if you
do adopt the convention of static fields, then you would likely get
enmeshed in Java's interesting class- and static-field initialization...
Another approach would be to use annotations or enumerated pointcuts to
specify fields backed with preferences, or to have read/write points,
or to adopt naming conventions or a combination: specially-named
getter/setters - all depending on whether the programmer should be
concerned with whether something is backed by a preference. Perhaps
aspects supporting Sun's Preferences could work along the lines
set out by aspects supporting other forms of dependency inversion
(IPreferenceable.usePreferences?).
In my mind there are four classes of AspectJ code to publish:
- A particular solution that works
- A working solution with a particularly new or useful approach
- A reusable working ....
- ... that has general applicability
All are great on the user's list. The later ones are sample code,
and the last one is perhaps a library aspect. (There are of course
other considerations - maintainability, clarity, coolness, etc.)
I find that code progresses through these stages; I get something
that works, then find a better way to make it work (on the user
list?), and so forth.
I also liked your problem and solution statement. You might use the
notions of scattering/tangling and/or crosscutting explicitly to
see where AspectJ helps.
Wes
------------Original Message------------
From: "Vaidas Gasiunas" <gasiunas@xxxxxxxxxxxxxxxxxxxxxxxxxx>
To: aspectj-dev@xxxxxxxxxxx
Date: Fri, May-6-2005 2:19 AM
Subject: [aspectj-dev] Aspect for AspectJ Library: Transparent Usage of
Preferences
Hello to everyone,
Sorry, for formatting problems in the previous posting.
Here is a proposal for an aspect to be included in AspectJ library.
Problem statement:
Applications require preference and configuration data to adapt to the
needs
of different users and environments. JSDK provides Preferences API to
store
and retrieve such preferences. Below is an example how they can be
used:
import java.util.prefs.Preferences;
public class Application {
public static void main(String args[]) {
Preferences appPrefs =
Preferences.userNodeForPackage(Application.class);
if (userPrefs.getBoolean("showWelcomeScreen", true) {
showWelcomeScreen();
}
...
}
}
public class PreferencesEditor
{
public void setWelcomeScreen(boolean on) {
Preferences appPrefs =
Preferences.userNodeForPackage(Application.class);
appPrefs.setBoolean("showWelcomeScreen", on);
}
...
}
The problem with such usage is that it is error prone. For example we
can
mistype the name of the property "showWelcomeScreen", we can also make
wrong
assumption about its type, for example it can be stored using numbers 0
and
1. Default value must be provided in each place where the property is
requested. Refactorings which imply renaming or removing prefences can
lead
to undetected problems.
Finally, it would be difficult to change the way application stores its
properties.
Solution:
The idea is to provide preferences as static class fields and write a
reusable aspect, which takes care about retrieving and storing these
properties. The classes containing preferences are marked by
implementing
PreferenceContainer interface.
public class AppPreferences implements PreferenceContainer {
public static boolean showWelcomeScreen = true;
/* initializer specifies the default value */
public static String logFile = "./application.log";
...
}
public class Application {
public static void main(String args[])
{
if (AppPreferences.showWelcomeScreen) {
showWelcomeScreen();
}
...
}
}
public class PreferencesEditor
{
public void setWelcomeScreen(boolean on) {
AppPreferences.showWelcomeScreen = on;
}
...
}
Such solution make their usage of preferences simple and type safe.
This way
of preference usage supports useful IDE features, such as code
completion
and reference search. The way preferences are actually retrieved and
stored
(Windows registry, properties file, xml file, etc.) can be easily
changed by
configuring the aspect.
See the first version of the aspect in the attachment (tested on AJDT
1.2.0M3 + Eclipse 3.0.2). Comments are welcome.
Regards,
-----------------
Vaidas Gasiunas
Software Technology Group
Darmstadt University of Technology
Hochschulstr. 10
64284 Darmstadt, Germany
e-mail: gasiunas@xxxxxxxxxxxxxxxxxxxxxxxxxx
phone: +49 6151 16 5478
fax: +49 6151 16 5410
www: http://www.st.informatik.tu-darmstadt.de/
_______________________________________________
aspectj-dev mailing list
aspectj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-dev
_______________________________________________
aspectj-dev mailing list
aspectj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-dev
