Hi Sreeni,
Thanks for sending this out.
In order to proceed, I think we need to decide on the interface between
JSFT's LDM and the POJO. First the LDM needs to "find" the POJO. How
do you propose we do this? Assuming that NO gui code is written for
this page, the URL itself will need to locate the POJO. This may mean
the URL has some encoded version of the ObjectName, or do you have
another idea?
After it is found, or some reference to it is found, how do we get
information from it? Should we use Class.getAnnotations()? And
similarly for Methods? Or will there be a reference (facade) to the
POJO that extracts this information and provides some API for us to use?
Another concern that I have is keeping GlassFish specific API's out of
JSFTemplating. I think we can achieve this, but keep this in mind while
thinking about how this works. This may mean that JSFT provides an
interface which it uses to walk the data, and a concrete implemenation
of that interface exists in the GlassFish GUI codebase which is able to
interact more directly with backend GlassFish code.
On the JSFT side, we need to consider what to do with this information.
We need to have a way to map an output-only or i/o component to a
concrete JSF component. Also, we should be able to specify some config
information describing default templates and maybe a means to override
that template for particular "viewId's."
Let's use the example you wrote and see if we can get this working.
Sreeni, let me know how you'd like to proceed in addressing these
issues. I'm open to meeting via irc, phone, or email. In the mean
time, I am going to think about this some more...
Thanks!
Ken
Sreenivas Munnangi wrote:
> Hi,
>
> In the first place, I would like to congratulate you on your efforts
> and making JSF Templating popular.
> I am glad to be involved with this forum and send the attached
> proposal for making JSF Templating even more useful and popular.
>
> You may see from the proposal that basically what I am proposing for
> is to discover the annotations on a POJO, create corresponding GUI and
> enable the runtime management.
>
> Please let me know your comments/suggestions and what it would take to
> make this happen.
>
> Thanks,
> Sreeni.
>
>
>
>
>> Proposal for exposing Management Info through JSF Templating.
>> -------------------------------------------------------------
>> Sreenivas Munnangi, 29jan08
>>
>> GlassFish V3 is based on modular architecture and provides for extensibility by enabling integration of external modules. These modules would like to be managed and monitored the same way GlassFish V3 does. To facilitate the runtime management, the external module will expose its management thru GUI so that the user experience is uniform.
>>
>> One approach is to ask the developer to come up with all the GUI code by himself so that it intergates into GlassFish V3 GUI. And an easier appraoch for simple CRUD functionality would be to ask the developer to annotate the POJO and discover those annotations at compile time or runtime and generate the GUI code ourselves instead of burdening the developer and I am sure many developers will love such a facility.
>>
>> For example, consider the following POJO and its interest in being exposed in GUI through the annotation @GUI
>>
>> @RuntimeMgmt
>> @GUI
>> public class MangeNewModule {
>>
>> @ManagedAttribute
>> public int getCacheSize() {...}
>>
>> @ManagedAttribute
>> public void setCacheSize(int size) {...}
>>
>> @ManagedAttribute
>> public String getModuleName() {...}
>>
>> @ManagedOperation
>> public void start() {...}
>>
>> @ManagedOperation
>> public void stop() {...}
>>
>> @ManagedOperation
>> public void refresh(Integer minThreshold, Integer maxThreshold) {...}
>> }
>>
>> Corresponding to the above annotations, the GUI is expected to display the following and allow for the update appropriately.
>>
>> ------------------------------------------------------
>> ManageNewModule:
>>
>> CacheSize: ____ <update>
>>
>> ModuleName: ____
>>
>> <start>
>>
>> <stop>
>>
>> MinThreshold: ____ MaxThreshold: ____ <refresh>
>> ------------------------------------------------------
>>
>> - CacheSize can be updated because it has setter and getter methods
>> - ModuleName cannot be updated because it doesn't have a setter
>> - start and stop methods need to be invoked without any parameters
>> - refresh method needs to be invoked with 2 parameters, minimum and maxmimum thresholds.
>>
>> Above is a simple scenario for us to get started and I am sure several improvements will be possible as we progress. Some of them include representing complex data types, and describining annotations in more detail to enable Rich Interface.
>>
>