© Copyright 2010-2011 Contributors. All rights reserved.

AspectJ 1.6.12 Readme

The full list of resolved issues in 1.6.12 is available here.

1.6.12 released 18-Oct-2011

1.6.12.RC1 available 3-Oct-2011

1.6.12.M2 available 18-Aug-2011

1.6.12.M1 available 7-Jun-2011

Notable Changes

RC1 - annotation value matching and !=

Prior to this change it was only possible to specify an annotation match like this:

get(@Anno(someValue=1) * *) || get(@Anno(someValue=3) * *)

Now it is possible to use != and write this:

get(@Anno(someValue!=2) * *)

This can enable a group of annotated elements to be more easily identified.

RC1 - More flexible pointcut/code wiring in aop.xml

Prior to this version the wiring was quite limited. In order to wire a pointcut to a piece of code the user needed to write an abstract aspect that included an abstract pointcut and some advice attached to that abstract pointcut. Then compile this aspect and finally write the XML to concretize the abstract pointcut. With 1.6.12 more flexibility has been added and for some cases there can be no need for that abstract aspect.

This is a work in progress but now you can write this in the aop.xml:


<concrete-aspect name="MyAspect">
  <before pointcut="execution(* Hello.say2(..)) AND args(message)"
   invokeClass="SomeRegularJavaClass" 
   invokeMethod="someMethod(JoinPoint tjp, java.lang.String message)"/>
  <after pointcut="execution(* Hello.say2(..)) AND args(message)"
   invokeClass="SomeRegularJavaClass" 
   invokeMethod="someOtherMethod(JoinPoint tjp, java.lang.String message)"/>
</concrete-aspect>

public class SomeRegularJavaClass {

  public static void someMethod(org.aspectj.lang.JoinPoint tjp, String s) {
    System.out.println("in advice4: s="+s+" at "+tjp);
  }
  
  public static void someOtherMethod(org.aspectj.lang.JoinPoint tjp, String s) {
    System.out.println("in advice5: s="+s+" at "+tjp);
  }
}

In this example there is a simple regular java class containing some static methods. In the XML these can be joined to pointcuts, kind as if they were advice. Notice in the XML it specifies:

Due to the method specification being in XML the parameter types must be fully specified. The only exception to this rule is that the AspectJ core types JoinPoint (and JoinPoint.StaticPart) do not have to be fully qualified (see the example above). Important: notice that in the case above which does argument binding, the names are bound according to the XML specification, not according to the parameter names in the Java code.

Around advice is also supported (the return type of the method must match the joinpoint return type). The example shows after advice, currently there is no way to specify either after returning or after finally, there is only after.

Expanding this further would enable support for all the code style features in the XML. Some of the language features like declare annotation cannot be done in annotation style aspects but the XML doesn't have the same kind of restrictions. If anyone wants to help out by fleshing this area of the weaver out, let me know and I'll help you get started!


M2 - thisAspectInstance (bug239649)

There is now a new well known name that you can use in the if clauses in your aspects. thisAspectInstance provides access to the aspect instance. Here is an example:

aspect X {
  boolean doit() {
    System.out.println("In instance check method doit()");
    return true;
  }

  before():execution(* m(..)) && if(thisAspectInstance.doit()){
    System.out.println(thisJoinPoint);
  }
}

Now why not just use X.aspectOf() instead of thisAspectInstance? Well thisAspectInstance is quite useful when working with abstract/concrete aspects:

abstract aspect X {
abstract pointcut p();

boolean doit() {
    return true;
  }

  before():p()  && if(thisAspectInstance.doit()){
    System.out.println(thisJoinPoint);
  }
}

aspect Y extends X {

  pointcut p(): execution(* m(..));

}

Now thisAspectInstance will be an instance of the Y, not X. It enables the aspect instance to be used in some kind of check/guard that will avoid the costly creation of a thisJoinPoint object if the advice isn't going to run. Note: right now this only works for singleton aspects. If you have need of it with other instantiation models, please comment on https://bugs.eclipse.org/bugs/show_bug.cgi?id=239649

M2 - weaving groovy

Although we have been successfully weaving groovy for a long time, it is becoming more popular and a few issues have been uncovered when using non-singleton aspects with groovy code. These have been fixed.

M2 - AJDT memory

The release notes for the last few versions of AspectJ have mentioned two options (minimalModel and typeDemotion) which can be switched on to reduce memory consumption. They have had enough field testing now and from 1.6.12.M2 onwards they are on by default. Users should see a reduction in memory consumed by AspectJ projects in AJDT. It won't affect load time weaving. It may also help command line (or Ant) compile time weaving. If these options cause a problem then please raise a bugzilla but in the interim you could work around the problem by actively turning them off by specifying -Xset:minimalModel=false,typeDemotion=false in the project properties for your AspectJ project.

M2 - Java7 weaving support

Some preliminary work has been done to support Java7. Java7 class files must contain the necessary extra verifier support attributes in order to load successfully on a Java7 VM - the attributes were only optional in Java6. It is possible to force loading of classes missing the attributes but that requires use of a -XX option. AspectJ 1.6.12.M2 should create these for you if you weave Java7 level class files. Nothing has been done yet to rebase AspectJ on a version of the Eclipse compiler that supports Java7 language constructs - that will happen after Eclipse 3.7.1 is out.


M1 - synthetic is supported in pointcut modifiers 327867

It is now possible to specify synthetic in pointcuts:

pointcut p(): execution(!synthetic * *(..));

M1 - respect protection domain when generating types during weaving 328099

This enables us to weave signed jars correctly. AspectJ sometimes generates closure classes during weaving and these must be defined with the same protection domain as the jar that gave rise to them. In 1.6.12.M1 this should now work correctly.

M1 - Suppressions inline with the JDT compiler 335810

Starting with Eclipse 3.6, the Eclipse compiler no longer suppresses raw type warnings with @SuppressWarnings("unchecked"). You need to use @SuppressWarnings("rawtypes") for that. AspectJ has now been updated with this rule too.

M1 - Optimized annotation value binding for ints 347684

The optimized annotation value binding now supports ints - this is for use when you want to match upon the existence of an annotation but you don't need the annotation, you just need a value from it. This code snippet shows an example:

@interface SomeAnnotation {
  int i();
}

before(int i): execution(* *(..)) && @annotation(SomeAnnotation(i)) {

Binding values in this way will result in code that runs *much* faster than using pointcuts that bind the annotation itself then pull out the value.

Under that same bug some changes were made to match values by name when binding too. Suppose the annotation had multiple int values, how would we select which int to bind? AspectJ will now use the name (if it can) to select the right value:

@interface SomeAnnotation {
  int mods();
  int flags();
}

before(int flags): execution(* *(..)) && @annotation(SomeAnnotation(flags)) {

Here the use of 'flags' as the name of the value being bound will ensure the 'flags' value from any SomeAnnotation is bound and not the 'mods' value.

#n32'>32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210
---
title: Building the UI
order: 2
layout: page
---

[[application.architecture]]
= Building the UI

Vaadin Framework user interfaces are built hierarchically from components, so that the
leaf components are contained within layout components and other component
containers. Building the hierarchy starts from the top (or bottom - whichever
way you like to think about it), from the [classname]#UI# class of the
application. You normally set a layout component as the content of the UI and
fill it with other components.

[source, java]
----
public class MyHierarchicalUI extends UI {
    @Override
    protected void init(VaadinRequest request) {
        // The root of the component hierarchy
        VerticalLayout content = new VerticalLayout();
        content.setSizeFull(); // Use entire window
        setContent(content);   // Attach to the UI

        // Add some component
        content.addComponent(new Label("<b>Hello!</b> - How are you?", 
                ContentMode.HTML));

        Grid<Person> grid = new Grid<>();
        grid.setCaption("My Grid");
        grid.setItems(GridExample.generateContent());
        grid.setSizeFull();
        content.addComponent(grid);
        content.setExpandRatio(grid, 1); // Expand to fill
    }
}
----

The component hierarchy is illustrated in <<figure.application.architecture.schematic>>.

[[figure.application.architecture.schematic]]
.Schematic diagram of the UI
image::img/ui-schematic.png[width=80%, scaledwidth=100%]

The actual UI is shown in <<figure.application.architecture.example>>.

[[figure.application.architecture.example]]
.Simple hierarchical UI
image::img/ui-architecture-hierarchical.png[width=70%, scaledwidth=90%]

Instead of building the layout in Java, you can also use a declarative design, as described later in <<application-declarative#application.declarative,"Designing UIs Declaratively">>.
The examples given for the declarative layouts give exactly the same UI layout as built from the components above.
The easiest way to create declarative designs is to use Vaadin Designer.

The built-in components are described in
<<../components/components-overview.asciidoc#components.overview,"User
Interface Components">> and the layout components in
<<../layout/layout-overview.asciidoc#layout.overview,"Managing
Layout">>.

The example application described above just is, it does not do anything. User
interaction is handled with event listeners, as described a bit later in
<<application-events#application.events,"Handling
Events with Listeners">>.

[[application.architecture.architecture]]
== Application Architecture

Once your application grows beyond a dozen or so lines, which is usually quite
soon, you need to start considering the application architecture more closely.
You are free to use any object-oriented techniques available in Java to organize
your code in methods, classes, packages, and libraries. An architecture defines
how these modules communicate together and what sort of dependencies they have
between them. It also defines the scope of the application. The scope of this
book, however, only gives a possibility to mention some of the most common
architectural patterns in Vaadin applications.

The subsequent sections describe some basic application patterns. For more
information about common architectures, see
<<../advanced/advanced-architecture#advanced.architecture,"Advanced
Application Architectures">>, which discusses layered architectures, the
Model-View-Presenter (MVP) pattern, and so forth.

[[application.architecture.composition]]
== Compositing Components

User interfaces typically contain many user interface components in a layout
hierarchy. Vaadin provides many layout components for laying contained
components vertically, horizontally, in a grid, and in many other ways. You can
extend layout components to create composite components.


[source, java]
----
class MyView extends VerticalLayout {
    TextField entry = new TextField("Enter this");
    Label display = new Label("See this");
    Button click = new Button("Click This");

    public MyView() {
        addComponent(entry);
        addComponent(display);
        addComponent(click);

        setSizeFull();
        addStyleName("myview");
    }
}

// Create an instance of MyView
Layout myview = new MyView();
----

While extending layouts is an easy way to make component composition, it is a
good practice to encapsulate implementation details, such as the exact layout
component used. Otherwise, the users of such a composite could begin to rely on
such implementation details, which would make changes harder. For this purpose,
Vaadin has the special wrappers [classname]#Composite# and
[classname]#CustomComponent#, which hide the content representation.


[source, java]
----
class MyView extends CustomComponent {
    TextField entry = new TextField("Enter this");
    Label display = new Label("See this");
    Button click = new Button("Click This");

    public MyView() {
        Layout layout = new VerticalLayout();

        layout.addComponent(entry);
        layout.addComponent(display);
        layout.addComponent(click);

        setCompositionRoot(layout);
        setSizeFull();
    }
}

// Create an instance of MyView
MyView myview = new MyView();
----

For a more detailed description of [classname]#Composite# and [classname]#CustomComponent#, see
<<../components/components-customcomponent#components.customcomponent,"Composition
with Composite and CustomComponent">>.


[[application.architecture.navigation]]
== View Navigation

While the simplest applications have just one __view__ (or __screen__), most of them often require several.
Even in a single view, you often want to have sub-views,
for example to display different content.
<<figure.application.architecture.navigation>> illustrates a typical navigation
between different top-level views of an application, and a main view with
sub-views.

[[figure.application.architecture.navigation]]
.Navigation Between Views
image::img/view-navigation-hi.png[width=80%, scaledwidth=100%]

The [classname]#Navigator# described in <<../advanced/advanced-navigator#advanced.navigator,"Navigating in an Application">> is a view manager that provides a flexible way to navigate between views and sub-views, while managing the URI fragment in the page URL to allow bookmarking, linking, and going back in the browser history.

Often Vaadin application views are part of something bigger.
In such cases, you may need to integrate the Vaadin applications with the other website.
You can use the embedding techniques described in <<../advanced/advanced-embedding#advanced.embedding,"Embedding UIs in Web Pages">>.


[[application.architecture.accessing]]
== Accessing UI, Page, Session, and Service

You can get the UI and the page to which a component is attached to with
[methodname]#getUI()# and [methodname]#getPage()#.

However, the values are [literal]#++null++# until the component is attached to
the UI, and typically, when you need it in constructors, it is not. It is
therefore preferable to access the current UI, page, session, and service
objects from anywhere in the application using the static
[methodname]#getCurrent()# methods in the respective [classname]#UI#,
[classname]#Page#, [classname]#VaadinSession#, and [classname]#VaadinService#
classes.


[source, java]
----
// Set the default locale of the UI
UI.getCurrent().setLocale(new Locale("en"));

// Set the page title (window or tab caption)
Page.getCurrent().setTitle("My Page");

// Set a session attribute
VaadinSession.getCurrent().setAttribute("myattrib", "hello");

// Access the HTTP service parameters
File baseDir = VaadinService.getCurrent().getBaseDirectory();
----

You can get the page and the session also from a [classname]#UI# with
[methodname]#getPage()# and [methodname]#getSession()# and the service from
[classname]#VaadinSession# with [methodname]#getService()#.

The static methods use the built-in ThreadLocal support in the classes.
ifdef::web[]
The pattern is described in <<../advanced/advanced-global#advanced.global.threadlocal,"ThreadLocal Pattern">>.
endif::web[]