[Design the new POJO MicroContainer] - Re: Precedence
by adrian＠jboss.org
"alesj" wrote :
| I changed the B into E, and left the other parts of the test unchanged.
| OK? :-)
|
No that misses the whole point of the test.
A) inputs=test1 outputs=null
B) inputs=null outputs=null
C) inputs=null outputs=test1
It is actually irrelevant where (B) is compared to (A) or (C)
If it just used Ordered.COMPARATOR in the order above then (B) would
get in the way of the sorting.
What is relevant is that A inputs from C, so the correct orders is either
1) C, A, B
2) B, C, A
3) C, B, A
(3) is obviously wrong since C and B are unrelated by attachment
they should be ordered by Ordered.COMPARATOR
but either (1) or (2) is correct.
The test assumes the following heuristic (which was true of the old sort):
"Favour the order in which deployers are deployed".
i.e. Since B was deployed after A and there is no reason why B should be
sorted in front of A, therefore it always remains after A.
i.e. (1) is the correct order.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4061349#4061349
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4061349
18 years, 9 months
[Design of JBoss Portal] - Re: Initial UI Server Prototype Discussion
by julien＠jboss.com
it could be an option, however I would prefer to separate protocol request state from protocol request meta data.
On example is that the type of a request is a meta data and I want rather to use a design which use annotations.
| public abstract class UIRequest implements Serializable { ... }
|
| @type("MoveWindow")
| public class SomeRequest extends UIRequest { ... }
|
It is useful to put annotations on the protocol elements. We will certainly have other meta data that describes the behavior of a protocol request.
For instance if you look at the command framework today in core it has the same notion of meta data but it is implemented using java and not annotations.
And the few metadata present on the controller command drive the behavior of the execution of the command at runtime.
| public class ControllerCommand
| {
| ...
| /** Return the meta data of this command. */
| public abstract CommandInfo getInfo();
| ...
| }
|
There are also other valid points that makes me prefer a hierarchy over an objects that aggregates all:
- easier to debug
- easier to categorize
- inheritance and polymorphism can be leveraged
"sohil.shah(a)jboss.com" wrote : The protocol needs to be modelled under the form of a hierarchy of serializable objects.
|
| What do you think of a more flexible object model with a leaner hierarchy...
|
| Something like this:
|
|
| | public class UIRequest implements Serializable
| | {
| | private String requestType; //this signifies what type of function is asked for like
| | getUIElement, processURL, moveWindow, removeWindow
| |
| | private Map attributes; //this contains the data needed for a particular function
| | }
| |
|
| Something similar for UIResponse as well.
|
| This way more functions can probably be integrated into the system pretty easily as well.
|
| This would help to evolve the UIServer functionality over time while still keeping it lean and mean
|
| btw- Now that we want to integrate at the second phase of the controller, a well thought out object model becomes very important
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4061341#4061341
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4061341
18 years, 9 months
[Design of JBoss Portal] - Re: Initial UI Server Prototype Discussion
by julien＠jboss.com
thanks.
as said, the uiserver needs to define its data objects in order to be dependant only on the common module.
the implementations of the consumer side of the uiserver should be dependant on the server module.
the controller is going to be rewritten partly, so how this is integrated (core-serverui) will change probably.
"sohil.shah(a)jboss.com" wrote : >in the core-uiserver part, the current core controller should be reused with with separate >implementation of ResponseHandler that would adapt the current core controller command >framework to the ui server protocol.
|
| This point is interesting. According to this, Controller/UIServer integration would start in the second phase (processCommandResponse) instead of the third phase which is what is happening in the prototype.
|
| With that in mind, the UIServer will need to incorporate some more model objects.
|
| Let me re-architect the prototype to integrate in this phase
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4061337#4061337
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4061337
18 years, 9 months