Author Archive

Aranea-MVC 1.1.1

Wednesday, March 19th, 2008

For the wonderers—yes 1.1 final had rather a silent release in February and now is the time for nicely symmetrical minor version update that fixes a little bug and updates documentation that concerns Aranea javascript.

We’d also like to thank all people who have reported issues and keep our forums lively. We couldn’t have done it so far without you :)

First milestone of 1.2 branch which implements state versioning (and thus back-button support) is due within few days.

Letting end-user confirm destructive actions

Thursday, February 21st, 2008

Aranea 1.1 standard component chain enriches Environment with a context called ConfirmationContext. This can be used for executing some code conditionally, depending on user actions. Context interface is simple and consists of following methods:

public interface ConfirmationContext {
  void confirm(Closure onConfirmClosure, String message);
  String getConfirmationMessage();
}

When confirmation is registered (with confirm() method), rendering mechanism will present end-user with the browser standard message box and ask for confirmation of requested action. Depending on users choice, action encapsulated in onConfirmClosure either will get executed or not.

Combined with TransitionHandler, confirmation could be asked whenever the user performs navigation that would make active flow unreachable and flow contains data that has not yet been saved.

getFlowCtx().setTransitionHandler(
  new CancelConfirmingTransitionHandler(
     new ShouldConfirmOnUnsavedData(),
     "Some data not saved yet. Continue anyway?"
  )
);

Here CancelConfirmingTransitionHandler registers the confirmation whenever FlowContext.cancel() is called from active flow and Predicate ShouldConfirmOnUnsavedData evaluates to true. Only after user confirms the navigation event will flow transition actually be performed.

ConfirmationContext and TransitionHandlers together are a reliable and convenient way of preventing end-users shooting themselves in the foot :) .

Aranea-MVC 1.1-RC1

Thursday, February 7th, 2008

And … the 1.1-RC1 is here sooner than expected :) Mainly this is due to pushing back-button support into the 1.2 release cycle. It will still be done very soon (within this February). This release contains fixes for bugs which were reported since last milestone and documentation updates.

Enjoy!

Aranea-MVC 1.1-M6

Thursday, January 31st, 2008

Latest release is now very near to release candidate stage. Only major thing that we still want to add into the 1.1 branch is mechanism for supporting browser back button :)

See the change log & download the release. And let us know of anything that needs to be improved ;)

How Aranea Integration works: part I

Wednesday, October 24th, 2007

This is the first in the series of tutorial articles laying out the foundations of Aranea Integration in practical way. It introduces the base classes of Aranea Integration which form the core of server-side integration—handle sessions, requests and responses in a way that allows hosted components to function (keep this diagram open while reading!).

Base interface for Aranea components that host components/actions from whatever framework is called HostComponent.

/**
* Represents the Aranea {@link Component} that
* hosts some foreign framework component.
*/
public interface HostComponent extends Component {
  /**
  * This method must return the session attribute
  * <em>Map</em> specific to hosted component.
  * @return map that will be used for storing the
  *               session accessible to hosted foreign
  *               component
  */
  public Map getHostedSessionAttributes();
}

and has just one method — for retrieval of session attributes managed by the hosted component. The request and response are tuned to hosted components needs too, but since request and response in HTTP protocol are stateless, these need not be part of HostComponent interface but can be managed separately and statelessly. HostComponent base implementation is extremely simple:

/**
* Base class for Aranea widgets that host foreign
* components. Provides session storage for hosted
* foreign components.
*/
public class BaseHostWidget
extends BaseApplicationWidget implements HostComponent {
  private final Map sessionAttributeMap = new HashMap();

  public Map getHostedSessionAttributes() {
    return sessionAttributeMap;
  }
}

As one can see it completely lacks methods for actual management of session attributes.The class that manages session access is called SessionWrapper:

/* One and only constructor **/
public SessionWrapper(
    HttpSession session,
    HostComponent sessionHolder)

SessionWrapper ensures that the session modifications by hosted component will affect only the concrete hosted component. It is created anew at each request by IntegrationRequestWrapper (note that only way to access session in a web application is through current request).

Other base wrappers that make hosted component feel at home are already mentioned IntegrationRequestWrapper and IntegrationResponseWrapper. IntegrationRequestWrapper is created by some concrete HostComponent implementation, passing in the original request and itself.

new IntegrationRequestWrapper(
    HttpServletRequest original, HostComponent host);

The IntegrationResponseWrapper takes care that everything that is done to it only affects the wrapped instance — so that original request is left unchanged and can be passed to any number of other Aranea components or hosted components (in which case it is obviously wrapped in its own IntegrationRequestWrapper). Often some parts of original request are preprocessed in some way in IntegrationRequestWrapper extensions — i.e. the fully hierarchial component based request parameters that Aranea uses are converted into flat namespace for action-based frameworks, i.e.

public class BaseActionBasedRequestWrapper
(final HttpServletRequest request,
final HostComponent host) {
  super(request, host);
  preprocessRequestParameters();
}

where preprocessRequestParameters() takes all the ‘scoped’ data meant for hosted component and converts this into flat namespace parameters that action based frameworks expect. This allows to reuse actions many times on one page, as each action can receive separate data.

Foreign response itself is held in IntegrationResponseWrapper which allows HostComponent to post-process response when needed. Postprocessing is most often done to scope the request parameters expected by hosted component in a way that they will be unique. How exactly this is done is highly dependent on hosted framework. For action-based frameworks this might mean post-processing HTML forms, for component based frameworks the postprocessing might even be unnecessary when the hosted components’ ‘root’ component is given the right scope to begin with (i.e. with JSF NamingContainer).

Other crucial part of the IntegrationResponseWrapper is the overriden encodeURL(url) method. By servlet specification, all URLs that are to generate requests to (hosted) web application must go through this method before written out to response. IntegrationResponseWrapper overrides this method so that later incoming request can be identified as request to component hosted by Aranea. Identification is done by AraneaIntegrationFilter which is quite ordinary servlet filter, except it prevents the request from directly reaching the hosted framework and directs it to Aranea component hierarchy where it will be processed by all interested components including the HostComponent implementation which originally generated the request.

This briefly covers all current integration base classes. For more detailed information, one can take a look at org.araneaframework.integration.common package in the Aranea Integration project.

Aranea-MVC 1.1-M4

Monday, October 1st, 2007

We had somewhat longer gap between releases of M3 and M4 than usual, due to team taking vacation in July and being temporarily involved in three different projects as of late. But now for some highlights of 1.1-M4:

Also, there’s support for context menus in browsers, new control that is hybrid of text and select controls, plus for everyones coding pleasure FormWidget.addElement* and FilterHelper.* methods do not throw checked Exceptions anymore. See full changelog here.

Separate 1.1 demo application is also up. Obviously demos contain more explanations and stuff than mentioned here, so take a look! For everyone who has not yet noticed—already since early 1.0 days there are Widget source and Template source links in our demos (they are not easily spotted sometimes, look at the bottom left corner next to side menu :) ).

NB! It was not mentioned in changelog that comes with distro, but StandardFlowContainerWidget (standard implementation of FlowContext) was modified in a way that is incompatible with some older uses. Namely, when call stack is empty and parent FlowContext exists, StandardFlowContainerWidget.finish() and cancel() methods return control to parent FlowContext (meaning that once active StandardFlowContainerWidget is gone for good). In cases (mainly in menus) where this is unwanted, one must take care and call StandardFlowContainerWidget.setFinishable(false).

Aranea-MVC 1.0.11

Friday, August 31st, 2007

1.0.11 fixes issue with FormWidget.restoreBaseState(). There is some more though, details here.

Aranea-MVC 1.0.10

Monday, July 30th, 2007

There are quite few changes in this latest update to 1.0 branch, so I will list and comment on them all.

  • BeanFormWidget.readBean() method destroyed the content of sub-beans when writing nested form to a bean. This was both counterintuitive and wrong because the root bean and the child beans were handled differently (root bean fields were only updated, but child beans always created anew). This has been fixed
  • As the naming of BeanFormWidget.readBean() was very confusing, this method is now deprecated in favour of writeToBean(). Analogously, BeanFormWidget.writeBean() is deprecated in favour of readFromBean(). BeanFormWidget‘s readBean() and writeBean() will be removed in 1.1 branch.
  • TcdAndTldMerger utility that was distributed only in source form and had to be compiled separately is now included in aranea.jar. Its purpose and usage are documented here.

Aranea-MVC 1.1-M3

Sunday, June 24th, 2007

Most visible and important news about third milestone of Aranea-MVC 1.1 are:

  • pages containing update regions will not sometimes crash with NPE when active flow is finished during request
  • few of the Aranea specific request parameters were renamed (prefix was added). For example: ‘transactionId’ vs ‘araTransactionId’. Unless your custom client-side scripts or server-side filters directly used these parameter names (which should not be the case), this will not affect you.

Full changelog for the curious ones.

Aranea-MVC 1.1-M2 & 1.0.9

Thursday, June 14th, 2007

Those who attend our forums or subscribe to release feeds have already noticed that both stable and development branches saw new releases two days ago. Users of 1.1-M1 should definitely seek upgrade. Sourceforge has it all.