Custom UIs for media types

[Chathura C. Ekanayake]

I think it is useful to provide custom UIs for different media types in
the registry. Then the registry UI will render the resource contents in
meaningful UI components. Handler authors can bundle their handler
implementations with necessary UI files, so that once a handler is
added, registry knows how to render resource contents of that media type
as well.

We can give the responsibility of generating UIs entirely to the
handlers. Registry is not aware of the method used generate UIs. For
example, handler may use an xslt to generate UI for XML content. Once a
UI is generated, resource content is replaced with the generated HTML.
Now the problem is that we always don't need the content as an HTML. For
that we can introduce some URL pattern to get the UI or raw content.

/depts/marketing/server1.xml - gives the resource with raw xml content
/depts/marketing/server1.xml;view - gives the resource with content
filled with content view HTML
/depts/marketing/server1.xml;edit - gives the resource with content
filled with content edit HTML (HTML form)

Now we should have a way to process the edited content once a generated
HTML form is submitted. Handler authors can bundle an EditProcessor (a
Java class) to their handler implementations, so that the POST done from
the edit form is directed to that class. EditProcessor knows how to
extract parameters from the HTTP request and construct the raw resource
content from it. Once the edit processor builds the raw resource content
from the HTTP request, it calls the Registry API to put the resource.

Thoughts...

Thanks,
Chathura

_______________________________________________
Registry-dev mailing list
Registry-dev@...
http://wso2.org/cgi-bin/mailman/listinfo/registry-dev

[Ruwan Linton-3]

Hi Chathura,

Seems an interesting idea.... Please see my comments inline.
Chathura C. Ekanayake wrote:

>
> I think it is useful to provide custom UIs for different media types
> in the registry. Then the registry UI will render the resource
> contents in meaningful UI components. Handler authors can bundle their
> handler implementations with necessary UI files, so that once a
> handler is added, registry knows how to render resource contents of
> that media type as well.
>
> We can give the responsibility of generating UIs entirely to the
> handlers. Registry is not aware of the method used generate UIs. For
> example, handler may use an xslt to generate UI for XML content.

This is exactly how we have implemented the ESB mediator UIs. Each and
every mediator is presented to the user with two style sheets one for
view and the other for edit. We have used a conventional name if the
mediator is send then the xslt files will be;

send_view.xsl
send_edit.xsl

> Once a UI is generated, resource content is replaced with the
> generated HTML. Now the problem is that we always don't need the
> content as an HTML. For that we can introduce some URL pattern to get
> the UI or raw content.
>
> /depts/marketing/server1.xml - gives the resource with raw xml content
> /depts/marketing/server1.xml;view - gives the resource with content
> filled with content view HTML
> /depts/marketing/server1.xml;edit - gives the resource with content
> filled with content edit HTML (HTML form)

Cool, so when you do the URL mapping you can follow the same strategy
that we have used. That is on the servlet filter you can see the content
type of the resource that you are trying to serve and find the relevant
xslt from the convention. For example if the server1.xml is a WSDL file
you get the wsdl_edit.xml to process the server1.xml file before
presenting it to the user if it is the edit command. In the same way you
can retrieve the view WSDL if the user is looking for a view.
>
> Now we should have a way to process the edited content once a
> generated HTML form is submitted. Handler authors can bundle an
> EditProcessor (a Java class) to their handler implementations, so that
> the POST done from the edit form is directed to that class.
> EditProcessor knows how to extract parameters from the HTTP request
> and construct the raw resource content from it. Once the edit
> processor builds the raw resource content from the HTTP request, it
> calls the Registry API to put the resource.
Yes, we have used javascript for this part. I think you can provide an
EditProcessor interface and ask the Handler author to implement that so
that you can call the implemented method stated on the interface to
collect data and then you can use the Registry API to store it in the
registry.

+1 for the idea.

Thanks,
Ruwan

>
> Thoughts...
>
> Thanks,
> Chathura
>
> _______________________________________________
> Registry-dev mailing list
> Registry-dev@...
> http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
>

_______________________________________________
Registry-dev mailing list
Registry-dev@...
http://wso2.org/cgi-bin/mailman/listinfo/registry-dev

[Chathura C. Ekanayake]

I have completed the first phase of this implementation. Custom UIs are
supported by UIEnabledHandler class, which is extended from Hanlder.
Handler authors should implement the UIEnabledHandler.getView(...)
method to provide a HTML for viewing the resource content. HTML for
editing the resource content has to be generated in the
UIEnabledHandler.getEdit(...) method. In this way, handler authors get
the flexibility to generate custom UIs using whatever method they prefer
and UIs can generated for any text based content type. I have tested a
sample with this implementation and it worked well.

I am currently working on providing XSLT support for generating UIs.
This require some code in handlers with the current implementation. We
can generalize the XSLT code and provide a XSLT based UI handler, which
the users can use only by configuring the registry.xml.

We also need some nice samples to demonstrate the custom UIs, which is
my next step.

Thanks,
Chathura


_______________________________________________
Registry-dev mailing list
Registry-dev@...
http://wso2.org/cgi-bin/mailman/listinfo/registry-dev

[Chathura C. Ekanayake]

I added the support for generating custom UIs using XSLT. This
functionality is provided by the class XSLTBasedUIEnabledHandler, which
is extended from UIEnabledHandler. Two XSLTs has to be written to
generate view and edit UIs of the resource content. Then those two XSLTs
can be provided as properties to the XSLTBasedUIEnabledHandler. Handler
author should also provide an implementation of EditProcessor to process
the user input given to the edit UI. Below is a sample configuration.

<handler class="org.wso2.registry.jdbc.handlers.XSLTBasedUIEnabledHandler">

        <property
name="viewXSLT">/home/chathura/projects/reg-work/samples/view.xslt</property>
        <property
name="editXSLT">/home/chathura/projects/reg-work/samples/edit.xslt</property>

        <filter
class="org.wso2.registry.jdbc.handlers.filters.MediaTypeMatcher">
            <property
name="mediaType">application/vnd.server-config</property>
        </filter>

        <edit
processor="application/vnd.server-config">org.wso2.registry.jdbc.handlers.samples.custom.ServerConfigEditProcessor</edit>
</handler>

This configuration provides custom UIs for server configuration files
(identified by the media type application/vnd.server-config). Note that
users don't have to write any handlers. But ServerConfigEditProcessor
has to be written by the users.

Thanks,
Chathura

Chathura C. Ekanayake wrote:

> I have completed the first phase of this implementation. Custom UIs are
> supported by UIEnabledHandler class, which is extended from Hanlder.
> Handler authors should implement the UIEnabledHandler.getView(...)
> method to provide a HTML for viewing the resource content. HTML for
> editing the resource content has to be generated in the
> UIEnabledHandler.getEdit(...) method. In this way, handler authors get
> the flexibility to generate custom UIs using whatever method they prefer
> and UIs can generated for any text based content type. I have tested a
> sample with this implementation and it worked well.
>
> I am currently working on providing XSLT support for generating UIs.
> This require some code in handlers with the current implementation. We
> can generalize the XSLT code and provide a XSLT based UI handler, which
> the users can use only by configuring the registry.xml.
>
> We also need some nice samples to demonstrate the custom UIs, which is
> my next step.
>
> Thanks,
> Chathura
>
>
> _______________________________________________
> Registry-dev mailing list
> Registry-dev@...
> http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
>
>  

_______________________________________________
Registry-dev mailing list
Registry-dev@...
http://wso2.org/cgi-bin/mailman/listinfo/registry-dev

[Paul Fremantle-2]

Chathura

What is the easiest way I can try this out?

Paul

Chathura C. Ekanayake wrote:

> I added the support for generating custom UIs using XSLT. This
> functionality is provided by the class XSLTBasedUIEnabledHandler, which
> is extended from UIEnabledHandler. Two XSLTs has to be written to
> generate view and edit UIs of the resource content. Then those two XSLTs
> can be provided as properties to the XSLTBasedUIEnabledHandler. Handler
> author should also provide an implementation of EditProcessor to process
> the user input given to the edit UI. Below is a sample configuration.
>
> <handler class="org.wso2.registry.jdbc.handlers.XSLTBasedUIEnabledHandler">
>
>         <property
> name="viewXSLT">/home/chathura/projects/reg-work/samples/view.xslt</property>
>         <property
> name="editXSLT">/home/chathura/projects/reg-work/samples/edit.xslt</property>
>
>         <filter
> class="org.wso2.registry.jdbc.handlers.filters.MediaTypeMatcher">
>             <property
> name="mediaType">application/vnd.server-config</property>
>         </filter>
>
>         <edit
> processor="application/vnd.server-config">org.wso2.registry.jdbc.handlers.samples.custom.ServerConfigEditProcessor</edit>
> </handler>
>
> This configuration provides custom UIs for server configuration files
> (identified by the media type application/vnd.server-config). Note that
> users don't have to write any handlers. But ServerConfigEditProcessor
> has to be written by the users.
>
> Thanks,
> Chathura
>
> Chathura C. Ekanayake wrote:
>> I have completed the first phase of this implementation. Custom UIs are
>> supported by UIEnabledHandler class, which is extended from Hanlder.
>> Handler authors should implement the UIEnabledHandler.getView(...)
>> method to provide a HTML for viewing the resource content. HTML for
>> editing the resource content has to be generated in the
>> UIEnabledHandler.getEdit(...) method. In this way, handler authors get
>> the flexibility to generate custom UIs using whatever method they prefer
>> and UIs can generated for any text based content type. I have tested a
>> sample with this implementation and it worked well.
>>
>> I am currently working on providing XSLT support for generating UIs.
>> This require some code in handlers with the current implementation. We
>> can generalize the XSLT code and provide a XSLT based UI handler, which
>> the users can use only by configuring the registry.xml.
>>
>> We also need some nice samples to demonstrate the custom UIs, which is
>> my next step.
>>
>> Thanks,
>> Chathura
>>
>>
>> _______________________________________________
>> Registry-dev mailing list
>> Registry-dev@...
>> http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
>>
>>  
>
>
> _______________________________________________
> Registry-dev mailing list
> Registry-dev@...
> http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
>

--
Paul Fremantle
CTO and Co-Founder, WSO2
OASIS WS-RX TC Co-chair
VP, Apache Synapse

Office: [phone]
Cell: [phone]

blog: http://pzf.fremantle.org
paul@...

"Oxygenating the Web Service Platform", www.wso2.com

_______________________________________________
Registry-dev mailing list
Registry-dev@...
http://wso2.org/cgi-bin/mailman/listinfo/registry-dev

[Chathura C. Ekanayake]

Hi Paul,

I am working on a sample to demonstrate this functionality. I will
update this thread once it is complete.

Thanks,
Chathura

Paul Fremantle wrote:

> Chathura
>
> What is the easiest way I can try this out?
>
> Paul
>
> Chathura C. Ekanayake wrote:
>  
>> I added the support for generating custom UIs using XSLT. This
>> functionality is provided by the class XSLTBasedUIEnabledHandler, which
>> is extended from UIEnabledHandler. Two XSLTs has to be written to
>> generate view and edit UIs of the resource content. Then those two XSLTs
>> can be provided as properties to the XSLTBasedUIEnabledHandler. Handler
>> author should also provide an implementation of EditProcessor to process
>> the user input given to the edit UI. Below is a sample configuration.
>>
>> <handler class="org.wso2.registry.jdbc.handlers.XSLTBasedUIEnabledHandler">
>>
>>         <property
>> name="viewXSLT">/home/chathura/projects/reg-work/samples/view.xslt</property>
>>         <property
>> name="editXSLT">/home/chathura/projects/reg-work/samples/edit.xslt</property>
>>
>>         <filter
>> class="org.wso2.registry.jdbc.handlers.filters.MediaTypeMatcher">
>>             <property
>> name="mediaType">application/vnd.server-config</property>
>>         </filter>
>>
>>         <edit
>> processor="application/vnd.server-config">org.wso2.registry.jdbc.handlers.samples.custom.ServerConfigEditProcessor</edit>
>> </handler>
>>
>> This configuration provides custom UIs for server configuration files
>> (identified by the media type application/vnd.server-config). Note that
>> users don't have to write any handlers. But ServerConfigEditProcessor
>> has to be written by the users.
>>
>> Thanks,
>> Chathura
>>
>> Chathura C. Ekanayake wrote:
>>    
>>> I have completed the first phase of this implementation. Custom UIs are
>>> supported by UIEnabledHandler class, which is extended from Hanlder.
>>> Handler authors should implement the UIEnabledHandler.getView(...)
>>> method to provide a HTML for viewing the resource content. HTML for
>>> editing the resource content has to be generated in the
>>> UIEnabledHandler.getEdit(...) method. In this way, handler authors get
>>> the flexibility to generate custom UIs using whatever method they prefer
>>> and UIs can generated for any text based content type. I have tested a
>>> sample with this implementation and it worked well.
>>>
>>> I am currently working on providing XSLT support for generating UIs.
>>> This require some code in handlers with the current implementation. We
>>> can generalize the XSLT code and provide a XSLT based UI handler, which
>>> the users can use only by configuring the registry.xml.
>>>
>>> We also need some nice samples to demonstrate the custom UIs, which is
>>> my next step.
>>>
>>> Thanks,
>>> Chathura
>>>
>>>
>>> _______________________________________________
>>> Registry-dev mailing list
>>> Registry-dev@...
>>> http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
>>>
>>>  
>>>      
>> _______________________________________________
>> Registry-dev mailing list
>> Registry-dev@...
>> http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
>>
>>    
>
>  

_______________________________________________
Registry-dev mailing list
Registry-dev@...
http://wso2.org/cgi-bin/mailman/listinfo/registry-dev

[Chathura C. Ekanayake]

Hi Paul / all,

I implemented a sample handler to demonstrate the custom UI
functionality. It generates custom UIs for viewing and editing Axis2
module configuration files (module.xml). All the steps for building and
testing this sample is documented in the readme.txt file included with it.

Currently, handlers are invoked based on the media type of the resource.
Therefore, we have to define a media type to identify module
configuration files. I used "application/am+xml" for this sample (am -->
axis module). I think we have to introduce a handler engagement
mechanism based on the resource content as well. Once it is done, we can
configure this handler to engage based on the content of the xml file,
without defining a new media type. I think we can implement it with the
current filter design. But we have to think of the optimum method to
minimize the effect on normal resources.

Thanks,
Chathura

Chathura C. Ekanayake wrote:

> Hi Paul,
>
> I am working on a sample to demonstrate this functionality. I will
> update this thread once it is complete.
>
> Thanks,
> Chathura
>
> Paul Fremantle wrote:
>  
>> Chathura
>>
>> What is the easiest way I can try this out?
>>
>> Paul
>>
>> Chathura C. Ekanayake wrote:
>>  
>>    
>>> I added the support for generating custom UIs using XSLT. This
>>> functionality is provided by the class XSLTBasedUIEnabledHandler, which
>>> is extended from UIEnabledHandler. Two XSLTs has to be written to
>>> generate view and edit UIs of the resource content. Then those two XSLTs
>>> can be provided as properties to the XSLTBasedUIEnabledHandler. Handler
>>> author should also provide an implementation of EditProcessor to process
>>> the user input given to the edit UI. Below is a sample configuration.
>>>
>>> <handler class="org.wso2.registry.jdbc.handlers.XSLTBasedUIEnabledHandler">
>>>
>>>         <property
>>> name="viewXSLT">/home/chathura/projects/reg-work/samples/view.xslt</property>
>>>         <property
>>> name="editXSLT">/home/chathura/projects/reg-work/samples/edit.xslt</property>
>>>
>>>         <filter
>>> class="org.wso2.registry.jdbc.handlers.filters.MediaTypeMatcher">
>>>             <property
>>> name="mediaType">application/vnd.server-config</property>
>>>         </filter>
>>>
>>>         <edit
>>> processor="application/vnd.server-config">org.wso2.registry.jdbc.handlers.samples.custom.ServerConfigEditProcessor</edit>
>>> </handler>
>>>
>>> This configuration provides custom UIs for server configuration files
>>> (identified by the media type application/vnd.server-config). Note that
>>> users don't have to write any handlers. But ServerConfigEditProcessor
>>> has to be written by the users.
>>>
>>> Thanks,
>>> Chathura
>>>
>>> Chathura C. Ekanayake wrote:
>>>    
>>>      
>>>> I have completed the first phase of this implementation. Custom UIs are
>>>> supported by UIEnabledHandler class, which is extended from Hanlder.
>>>> Handler authors should implement the UIEnabledHandler.getView(...)
>>>> method to provide a HTML for viewing the resource content. HTML for
>>>> editing the resource content has to be generated in the
>>>> UIEnabledHandler.getEdit(...) method. In this way, handler authors get
>>>> the flexibility to generate custom UIs using whatever method they prefer
>>>> and UIs can generated for any text based content type. I have tested a
>>>> sample with this implementation and it worked well.
>>>>
>>>> I am currently working on providing XSLT support for generating UIs.
>>>> This require some code in handlers with the current implementation. We
>>>> can generalize the XSLT code and provide a XSLT based UI handler, which
>>>> the users can use only by configuring the registry.xml.
>>>>
>>>> We also need some nice samples to demonstrate the custom UIs, which is
>>>> my next step.
>>>>
>>>> Thanks,
>>>> Chathura
>>>>
>>>>
>>>> _______________________________________________
>>>> Registry-dev mailing list
>>>> Registry-dev@...
>>>> http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
>>>>
>>>>  
>>>>      
>>>>        
>>> _______________________________________________
>>> Registry-dev mailing list
>>> Registry-dev@...
>>> http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
>>>
>>>    
>>>      
>>  
>>    
>
>
> _______________________________________________
> Registry-dev mailing list
> Registry-dev@...
> http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
>
>  

_______________________________________________
Registry-dev mailing list
Registry-dev@...
http://wso2.org/cgi-bin/mailman/listinfo/registry-dev