JSF menu specs dratf 0.2
Abbas Adel
Dears,
I think that we should go public and design our menuing system for general usage. So I decided to rewrite the specification to meet the new goal.
From now we will call our menuing system as JSF-menu and we will consider it a subproject of MUFIX2
There are 4 roles needed to build MUIFX menuing system:
1- We need to make DTD or XML Schema
2- Java code to merge and cache the XML menus files
3- JSF component to display the menu to the end user based on their security roles
4- API to control the menuing system at runtime
1:We will talk first about the xml schema:
<menu
id menu identifier, required
name mneu name
desc menu desc
enable true or false
extendable true or false
deletable true or false
page link to page
module module name
role security rule
order display order
binding Reference to the component that can be used in a backing bean
render contorl render based on bean properity
action Directly specifies an outcome used by the navigation handler to determine the JSF page to load next
styleClass CSS class name
style Inline style information
tabindex html attribute
target The name of a frame in which a document is opened
// dhtlm events
onblur
onchange
onclick
ondblclick
onfocus
onkeydown
onkeypress
onkeyup
onmousedown
onmousemove
onmouseout
onmouseover
onmouseup
onselect
>
<item
id item identifier, required
name item name
desc item desc
enable true or false
deletable true or false
page link to page
module module name
role security rule
order display order
binding Reference to the component that can be used in a backing bean
render contorl render based on bean properity
action Directly specifies an outcome used by the navigation handler to determine the JSF page to load next
styleClass CSS class name
style Inline style information
tabindex html attribute
target The name of a frame in which a document is opened
// dhtlm events
onblur
onchange
onclick
ondblclick
onfocus
onkeydown
onkeypress
onkeyup
onmousedown
onmousemove
onmouseout
onmouseover
onmouseup
onselect
>
I modified the schema to meet JSF basic component requirements. You will notice that I removed to tags; menus, group. Instead we will use cascading menus to group menus. For example:
<menu id=”parent”>
<menu id=”child1” ..> .. </menu>
<menu id=”child2” ..> .. </menu>
</menu>
But if you want to display the child1 menu you should do.
<menu: display id=”child1” />
More about the display system later
2:Merging and caching system:
Each module will have its menu.xml so we will have to merge all the menus into single xml file to input it to the display unit. The display unit transfers the output menu into html unordered list <ul><li>. The following figure explain the process.
In the figure you will notice something strange; default-menu.xml and extra-menu.xml.
Default-menu.xml
the default-menu.xml contains all default menus the each module can extend. For example:
In defaut-menu.xml
<menu id=”about” … extendable=”true”>
In xxx-menu.xml
<menu id=”about”>
<item id”1” name=”menufia” …. >
</menu>
This mechanism allow each module to extend other menus.
extra-menu.xml
as I mentioned in menu requirements that we want the menuing system to be extendable at runtime. Here were extra-menu.xml comes where new menus will be added inside.
This separation allow us to restore the original menu by simply deleting extra-menu.xml. we can also backup the newly added menus by copying extra-menu.xml to another location.
So what do I mean by cache?
You should notice that there is a lot of menus xml files that need to be merged. Imagine that on each request the server will merge the menu xml files and then produce the output to the user. This will take a lot of processing power unnecessarily. So the good solution is to make a cache to hold the merged menu.xml on the hard desk.
So what happens when the user add another menu at runtime to extra-menu.xml?
The merge and cache process will happen again.
What about i18n?
As I said in the requirements we will enforce i18n. each module will have module-menu.xml and module-menu.properties. module-menu.xml will contain menu information and module-menu.properties will contain i18n information. We will have to merge and cache the properties files into single menu.properties. there will be default-menu.properties and extra-menu.properties for the same reason as above.
How menu will be extended?
To extend an menu you have to know its id and that menu should be marked as extendable=true.
<menu id=”about”>
<item id”1” name=”menufia” …. >
</menu>
During the merging process. The merge unit will start with default-menu.xml and merge it with each module menu then extra-menu.xml because extra-menu.xml is allowed to override any other menu. For example:
In default-menu.xml
<menu id=”about” name=”default.about” extendable=”true” ..>
<item id=”mufic” name=”default.mufic” enable=”true” .. />
</menu>
In xxx-menu.xml
<menu id=”xxx” name=”xxx.yyy” ..>
<item id=”yyy” name=”xxx.yyy” .. />
</menu>
<menu id=”about”..>
<item id=”xxx” name=”xxx.zzz” .. />
</menu>
In extra-menu.xml
<menu id=”about” name=”default.about” ..>
<item id=”mufic” name=”default.mufic” enable=”false”.. />
</menu>
Final menu.xml
<menu id=”about” name=”default.about” ..>
<item id=”mufic” name=”default.mufic” enable=”false”.. />
<item id=”xxx” name=”xxx.zzz” .. />
</menu>
<menu id=”xxx” name=”xxx.yyy” ..>
<item id=”yyy” name=”xxx.yyy” .. />
</menu>
xxx-menu.xml extends the about menu and extra-menu.xml overrides it
3: Display the menu:
As mentioned in the requirements that we need to enforce security roles, so the user without some permission cannot see some links. For example:
In xxx-menu.xml
<menu id=”xxx” name=”xxx.yyy” ..>
<item id=”1” name=”aaa” role=”admin” />
<item id=”2” name=”bbb” role=”user, admin” />
<item id=”3” name=”ccc” role=”user, admin” />
<item id=”4” name=”ddd” role=”admin” />
</menu>
The output menu to admin:
<ul>
<li>aaa</li>
<li>bbb</li>
<li>ccc</li>
<li>ddd</li>
</ul>
The output to user:
<ul>
<li>bbb</li>
<li>ccc</li>
</ul>
Notice that we omitted aaa, ddd in the user menu.
How to display the menu to the user?
we will have to make jsf component to use with the jsf-menu. It should see the manages beans in the context.
An example of the component:
<menu:display id=”xxx” styleClass=”top” … />
Anyway, we should discuss it later.
4: we should provide an API to control the menu at runtime.
Thanks my friends and waiting for comments
BISO
Ahmed Eltanahy
Dear Abbas,
It is very great but to do that we need all MUFIX developers to work in this menu, Are you want to do another project instead of MUFIX :D?
Why we need all MUFIX developers ?
Because we want:
· Developers specialized in JSF Component.
· Developers specialized in render.
· Developers specialized in XML.
· Developers specialized in data binding.
· Developer specialized in CSS.
But really I wish to do it, but where people who can do that?
I suggest every body replay this mail by the category which he want to work in it.
About me : I wish to work in 2 categories XML binding or JSF Component with render.