[Design of JBoss Portal] - Ajax status
by julien＠jboss.com
The ajax stuff today is mostly finished, the remaining stuff is about writing tests and clarify its how it is configured in the portal object tree. Here is the status of what has been done :
Two features have been implemented :
- Drag and drop, that works mostly with dashboard.
- Asynchronous portlet rendering
About the second one :
Fortunately I have been able to come up with a solution that does not need different URLs: a browser with javascript disabled will work with the same page.
When a portlet window is asynchronously handled, the URLs that target the portal are handled by an even handler and the request is done by an XHR (XmlHttpRequest). On the server the same CommandFactory decodes it and the command is executed as usual.
The main change relies in how the command response is interpreted by the response handler. The ClassicResponseHandler will transform the result usually in a full page rendering sent back to the browser. The AjaxResponseHandler will rather perform the minimal work and send a response to the client browser.
Due to limitations of the theme framework we are able to handle only changes that don't change the window configuration on a page. So maximizing a window or moving from away from maximizing will always perform a full page refresh. That limitation will probably be removed in the future with a smarter client side implementation.
The ajax part is smart enough to detect navigational state changes and is compatible with the IPC api we have. So page events that modify the window state of several portlets on the same page, or transorming an event into another will always update the portlets on the same page.
The protocol between the AjaxResponseHandler and the client side javascript is very simple for now and has 2 basic responses. The first one is making a redirection to the browser, the second one is updating several fragments on the page. Again in the future it will improve and will have richer responses (i.e more UI oriented).
The client side implementation still uses scriptaculous + prototype which is a decent choice so far (it works in IE6, FF, Safari and Opera). I had to make one css hack to support IE6 though. In the future we may use another technology.
The configuration is done either at the portal object level using one property and also at the portlet level. A portlet may want to never be handled asynchronously for some reason so it is possible to prevent a portlet from being handled as such by specifying it in jboss-portlet.xml. A page or portal can be marked as asynchronous using properties there.
Finally this part is of course experimental, so don't blame me too much for issues :-). Please make JIRA tasks for the one you find and I will fix them when I come back next Saturday.
If you want you want to disable ajax stuff, you can try :
1/ put false in the render set used
2/ tag the portlet as async false (look in portlet-samples which has an URLPortlet and AsyncURLPortlet)
3/ set the ajax property on the portal object to false (still in portlet-samples the -object.xml)
The remaining stuff I plan to do upon my return and after CR1 is :
- write documentation about how to configure it
- find good defaults
- improve the configuration
- document it
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4035623#4035623
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4035623
18 years, 11 months
[Design of JBossCache] - Rigid design of state transfer manager, factories, integrato
by supi
In one of our projects, we need to keep remote systems in sync with cache content. When a cluster node that already has some transient state connects or reconnects the cluster, incremental state update notifications must be provided, the default notifyAllNodesCreated() approach just doesn't cut it.
It seems that in order to do this in 2.0.0, I have to subclass DefaltStateTransferIntegrater and actually write what I need. Then, I have to subclass StateTransferFactory and/or at least StateTransferManager and override the getStateTransferIntegrator() method and return my own. Then replace the transfer manager in cache impl. Is this correct?
Shouldn't there be an easier way to do this, e.g. the ability to register a custom integrator with the state transfer factory? Or being able to pass my own factory to the default state manager? It seems that the code contains some generic design ideas but they are implemented in a static way that prevent them from actually being used. What do you think?
Basil
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4035603#4035603
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4035603
18 years, 11 months
[Design of JBossCache] - PojoInstance: ref count & notification
by supi
Hi, I am trying to build an adapter on top of CacheListener to create (to me useful) Pojo notifications. Unfortunately, I cannot determine if a pojo is being multi-attached or detached because PojoInstance's ref count is the same in local pre and post notification (IMO a bug). The problem is in InternalHelper:
| /**
| * Increment reference count for the pojo. Note that this is not thread safe or atomic.
| */
| int incrementRefCount(Fqn originalFqn, Fqn referencingFqn) throws CacheException
| {
| PojoInstance pojoInstance = getAopInstance(originalFqn);
| if (pojoInstance == null)
| throw new PojoCacheException("InternalDelegate.incrementRefCount(): null pojoReference for fqn: " + originalFqn);
|
| int count = pojoInstance.incrementRefCount(referencingFqn);
| // need to update it.
| put(originalFqn, PojoInstance.KEY, pojoInstance);
| return count;
| }
|
It is stated that the method is not thread safe but the instance's incrementRefCount and decrement methods are in fact synchronized. So, can I just clone the instance, increment and put or do I need to synchronize the whole thing? Shouldn't it be locked anyway, where does this happen? Are there any other effects that I should be aware of that prevent us from doing:
| PojoInstance updatedInstance = (PojoInstance)pojoInstance.clone();
| int count = newInstance.incrementRefCount(referencingFqn);
| // need to update it.
| put(originalFqn, PojoInstance.KEY, updatedInstance);
|
Thanks,
Basil
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4035598#4035598
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4035598
18 years, 11 months
[Design of JBossCache] - Re: JBCACHE-1004 and JBCACHE-1005
by supi
"manik.surtani(a)jboss.com" wrote : Well, one workaround is to use a return type rather than a cast, which is valid:
| .
"jason.greene(a)jboss.com" wrote :
| You don't need to do this. Since a DI framework does this at runtime the generics info is irrelevant. So you can declare the injected type to be whatever you want.
Ok, there will be all kinds of workarounds (subclasses, wrappers, getters etc.) at compile time or (type-less) wiring at runtime that make me think: what's the point? The only benefit I see is type-safety that affects about 2-3 users who only put one kind of objects into the cache. Everyone else has to deal with this new inflexibility in their own way, potentially introducing new bugs, clumsy workarounds, unreadable code, unsafe code (e.g. disable unchecked warnings in whole methods), etc. And lets not forget the cache library itself. More letters, less readable code => more bugs.
In my opinion, at this point a step in the wrong direction.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4035593#4035593
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4035593
18 years, 11 months