How to get SweetDEV RIA JavaScript models ?
Since the version 2.2, a new method of JavaScript instantiation has been set. No more JavaScript vars are created, all is recorded in the SweetDevRia JavaScript repository.

To target an instance, a shortcut has been set up, which should be intuitive for every "JavaScript familiar developer":

SweetDevRia.$('${compId}');


This syntax will return you a SweetDEV RIA JavaScript instance of the component created with the id ${compId}. You can then manipulate it as you wish.



For example, opening a closed window (id='window') can be performed with the following line of code :

	<input></input>
[top]

How to override the JavaScript before/after functions?
We are trying to do our best to provide the most flexible code we can. In order to, we trigger some empty functions designed to be overridden on need. This avoid you to copy a whole function to bind some code inside, and so to meet some upgrading version incompatibilities, or break a process.

These functions are easily recognizable as they start with the before/after keywords (see the JsDoc section to have an overview of the ones provided).

To override one of these functions, simply add the following code after the resourcesImport tag :

<script>
    // Global syntax
	/*
	SweetDevRia.ComponentClassName[.prototype].functionName = function(){ 
		// my custom content 
	};
	*/
	
	//Specific sample
	SweetDevRia.Window.prototype.afterOpen = function(){
	   alert('Window Open');
	};
	 
</script>


If these functions does not fit the requirements for your customization, it's up to you to decide to override some real processing functions, but be aware of the possible problems described above.
[top]

How to manage the SweetDEV RIA components server side models?
Some components (the Ajax ones) are composed of a client and a server model.

The clients models can be targeted as defined in the previous FAQ part.

The management of the server ones is a bit more elaborated than the client models.



From version 3.0, a new Java model management has been set up. It is now possible to easily recover your components states from a page to an other one.

Each component is related to a page, defined by a pageName (ex-RiaPageId), and its id. Each couple pageName/id is stored in session and the components states are restored if a model has already been created for this couple. To take control over this pageName, 2 way are provided.
  • An attribute on the resourcesImport tag has been added to define this pageName. It is recommended to set one for everyPage where a server models targeting is required.

    Setting it by yourself permits to have a full control on the server side models storing, by defining yourself the couple pageName/id.

    If no pageName is defined, the one that will be set on the page depends on the propagatePageName configuration.
  • A global property for the whole application, defined in the ria-config.xml file, named propagatePageName.

    If false a new pageName will be generated for every page where the attribute pageName of the tag resourcesImport will be empty. If true the previous pageName for this session will be propagate for every page where the attribute pageName of the tag resourcesImport will be empty, allowing the components to restore their state from a page to an other. To keep some backward compatibility, this property is set to false by default.

It is now possible to target the session models and perform some processing on them.

This can be easily done by using the API of com.ideo.sweetdevria.page.PageManager, coupled to the com.ideo.sweetdevria.page.Page classes containing the models for every pages.

	RiaComponentModel model = PageManager.getPage(session, pageId).getModel(modelId);
	GridModel model = (GridModel)PageManager.getPage(session, "pageId").getModel("gridId");
                       




Let's assume we defined a simplegrid, id gridId, on pageName gridpage.

On an action, the user get redirected on a second page where the same grid id appears :
  • If the second page is named "gridpage", the grid will be rendered as left on the first one.
  • If the second page is named, but differently than "gridpage", a new grid will be displayed, with its default configuration.
  • If the second page is not named, the grid will restore its state depending of the propagatePageName configuration.




In spite of this page management, you might expect the possibility for a page to be fully stateful, excepting for a single component.

This behavior can be easily set up by setting the stateful attribute, available on all the tags of the stateful components.

The value of this attribute overrides the page settings and, therefore, is the one that must be filled with the most care.



To sum up :

  • Setting the stateful attribute to true is the default value : it let the component state depending on the page setting.
  • Setting the stateful attribute to false is a custom value : it force the component to recreate a clean model each time the tag is reevaluated.


As you might expect, the configuration of the application/pages can be defined from many ways, and the states of the server side models must be studied carefully to fulfill the desired behavior.
[top]

How to be notified on a server model modification?
A system of notification has been set up to allow you to be notified on a server model modification.

In order to implement this feature, you have to write your own listener and add it to the model you want to be informed from.

This can be easily performed, just read and get inspired of this piece of code written in the JSP :



					
	<ria:fileUpload></ria:fileUpload>

	
	FileUploadModel myFile = (FileUploadModel) PageManager.getPage(request).getModel("file1");
	myFile.addEventTypeListener(new IRiaListener(){
		public void handleEvent(com.ideo.sweetdevria.event.RiaEvent _evt){
			System.out.println("add");
		}
	}, FileUploadModel.Events.UPLOAD_FILE);
	myFile.addEventTypeListener(new IRiaListener(){
		public void handleEvent(com.ideo.sweetdevria.event.RiaEvent _evt){
			System.out.println("delete");
		}
	}, FileUploadModel.Events.DELETE_FILE);
	myFile.addEventListener(new IRiaListener(){
		public void handleEvent(com.ideo.sweetdevria.event.RiaEvent _evt){
			System.out.println("add or delete");
		}
	});
					
					
					


You can register on any Events, defined as an inner class of each server models.

The parameter _evt contains a param property containing the parameters that have been sent by the client in order to process the server modification.
[top]

How to define the server side model synchronization frequency?
Each client modification on a stateful component is reflected on the server to keep the model state through pages, or deal with the information the user provided.

By default, this synchronization is processed everytime an Ajax request has to be processed. A stack of event is sent to the server that will reflect every change on every component.

This synchronization is also triggered on page unload to flush the stack.



You can easily take control of this synchronization by setting the synchroMode attribute of the resourcesImport tag. Through this attribute, you can define a synchronization strategy, flushing the stack depending on seconds elapsed or number of events stored.

  • The attribute is set to default by default.
  • The synchronize on seconds elapsed, set it to XXXs, with XXX the number of seconds to wait before synchronizing.
  • The synchronize on number of events stacked, set it to XXXe, with XXX the number of events to stack before synchronizing. An event stack is, for example, the selection of a node of a tree component. This number can grow really fast.
  • To synchronize manually, call the piece of JavaScript code : SweetDevRia.ComHelper.fireEvent(null, true);, true defining the synchronous state of the call.


It's up to you to decide which way the synchronization should occur for your pages.



Note that without stateful component in the page, the synchronization is useless.
[top]