Re: [Dev] GSoC 2014 : Implement Registry Extension (RXT) 2.0 + Associated UI support

2014-08-17 Thread Iresha Udayangani
Hi all,

I wrote couple of blog posts covering the project.

http://ireshapm.blogspot.com/2014/08/implement-registry-extension-rxt-20.html

http://ireshapm.blogspot.com/2014/08/use-jaggery-ws-request-to-call-product_77.html

I appreciate any suggestions regarding the work done.

Thanks.




On Tue, Aug 12, 2014 at 6:47 PM, Iresha Udayangani iresh...@gmail.com
wrote:

 Hi Shelan,

 Yes, there are few changes in the server side as well. I have committed
 the changes to
 https://github.com/ireshapm0/carbon-governance/commits/dev-rxt-json

 I have added a new Admin Service method (addJSONRXTResource) to
 ManageGenericArtifactService. So you will have to build and replace the jar
 of org.wso2.carbon.governance.generic component, before using the JApp.

 @Subash: Actually I was talking about the Edit RXT UI, not the Add
 Metadata UI(in ES).

 Thanks.


 On Mon, Aug 11, 2014 at 10:10 PM, Shelan Perera she...@wso2.com wrote:

 Hi Iresha,

 Is there anything to be done at the server side or can we just save the
 artifact in the UI? I got your new changes and deployed the app. But when i
 try to save the
 artifact i got the following error. Any idea on this ?. Have you
 committed all your changes to the Git?


 [2014-08-11 21:58:54,677]  INFO
 {org.wso2.carbon.core.services.util.CarbonAuthenticationUtil} -
  'admin@carbon.super [-1234]' logged in at [2014-08-11 21:58:54,677+0530]
 [2014-08-11 22:01:01,385]  INFO
 {org.jaggeryjs.jaggery.app.mgt.TomcatJaggeryWebappsDeployer} -  Deployed
 webapp:
 StandardEngine[Catalina].StandardHost[localhost].StandardContext[/ArtifactBuilder-1].File[/home/shelan/wso2/gsoc-mentoring/wso2greg-4.6.0/repository/deployment/server/jaggeryapps/ArtifactBuilder-1]
 [2014-08-11 22:02:36,008] ERROR
 {org.jaggeryjs.hostobjects.ws.WSRequestHostObject} -  Error occured while
 invoking the service
 org.apache.axis2.AxisFault: The endpoint reference (EPR) for the
 Operation not found is
 https://localhost:9443/services/ManageGenericArtifactService and the WSA
 Action = urn:addJSONRXTResource. If this EPR was previously reachable,
 please contact the server administrator.
  at
 org.apache.axis2.util.Utils.getInboundFaultFromMessageContext(Utils.java:531)
 at
 org.apache.axis2.description.OutInAxisOperationClient.handleResponse(OutInAxisOperation.java:367)
  at
 org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:413)
 at
 org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:224)
  at
 org.apache.axis2.client.OperationClient.execute(OperationClient.java:149)
 at
 org.apache.axis2.client.ServiceClient.sendReceive(ServiceClient.java:554)
  at
 org.jaggeryjs.hostobjects.ws.WSRequestHostObject.jsFunction_send(WSRequestHostObject.java:362)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  at java.lang.reflect.Method.invoke(Method.java:606)
 at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:126)
  at org.mozilla.javascript.FunctionObject.call(FunctionObject.java:386)
 at org.mozilla.javascript.optimizer.OptRuntime.call1(OptRuntime.java:32)
  at
 org.jaggeryjs.rhino.ArtifactBuilder__1.c1._c_script_0(/ArtifactBuilder-1//ws-rxt.jag:16)
 at
 org.jaggeryjs.rhino.ArtifactBuilder__1.c1.call(/ArtifactBuilder-1//ws-rxt.jag)
  at
 org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:394)
 at org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:3091)
  at
 org.jaggeryjs.rhino.ArtifactBuilder__1.c1.call(/ArtifactBuilder-1//ws-rxt.jag)
 at
 org.jaggeryjs.rhino.ArtifactBuilder__1.c1.exec(/ArtifactBuilder-1//ws-rxt.jag)
  at
 org.jaggeryjs.scriptengine.engine.RhinoEngine.execScript(RhinoEngine.java:570)
 at
 org.jaggeryjs.scriptengine.engine.RhinoEngine.exec(RhinoEngine.java:273)
  at
 org.jaggeryjs.jaggery.core.manager.WebAppManager.execute(WebAppManager.java:432)
 at
 org.jaggeryjs.jaggery.core.JaggeryServlet.doPost(JaggeryServlet.java:29)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:755)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
  at
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
 at
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
  at
 org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:749)
 at
 org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:487)
  at
 org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:379)
 at
 org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:339)
  at
 org.jaggeryjs.jaggery.core.JaggeryFilter.doFilter(JaggeryFilter.java:21)
 at
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
  at
 

Re: [Dev] GSoC 2014 : Implement Registry Extension (RXT) 2.0 + Associated UI support

2014-08-12 Thread Iresha Udayangani
Hi Shelan,

Yes, there are few changes in the server side as well. I have committed the
changes to
https://github.com/ireshapm0/carbon-governance/commits/dev-rxt-json

I have added a new Admin Service method (addJSONRXTResource) to
ManageGenericArtifactService. So you will have to build and replace the jar
of org.wso2.carbon.governance.generic component, before using the JApp.

@Subash: Actually I was talking about the Edit RXT UI, not the Add Metadata
UI(in ES).

Thanks.


On Mon, Aug 11, 2014 at 10:10 PM, Shelan Perera she...@wso2.com wrote:

 Hi Iresha,

 Is there anything to be done at the server side or can we just save the
 artifact in the UI? I got your new changes and deployed the app. But when i
 try to save the
 artifact i got the following error. Any idea on this ?. Have you committed
 all your changes to the Git?


 [2014-08-11 21:58:54,677]  INFO
 {org.wso2.carbon.core.services.util.CarbonAuthenticationUtil} -
  'admin@carbon.super [-1234]' logged in at [2014-08-11 21:58:54,677+0530]
 [2014-08-11 22:01:01,385]  INFO
 {org.jaggeryjs.jaggery.app.mgt.TomcatJaggeryWebappsDeployer} -  Deployed
 webapp:
 StandardEngine[Catalina].StandardHost[localhost].StandardContext[/ArtifactBuilder-1].File[/home/shelan/wso2/gsoc-mentoring/wso2greg-4.6.0/repository/deployment/server/jaggeryapps/ArtifactBuilder-1]
 [2014-08-11 22:02:36,008] ERROR
 {org.jaggeryjs.hostobjects.ws.WSRequestHostObject} -  Error occured while
 invoking the service
 org.apache.axis2.AxisFault: The endpoint reference (EPR) for the Operation
 not found is https://localhost:9443/services/ManageGenericArtifactService
 and the WSA Action = urn:addJSONRXTResource. If this EPR was previously
 reachable, please contact the server administrator.
  at
 org.apache.axis2.util.Utils.getInboundFaultFromMessageContext(Utils.java:531)
 at
 org.apache.axis2.description.OutInAxisOperationClient.handleResponse(OutInAxisOperation.java:367)
  at
 org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:413)
 at
 org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:224)
  at
 org.apache.axis2.client.OperationClient.execute(OperationClient.java:149)
 at
 org.apache.axis2.client.ServiceClient.sendReceive(ServiceClient.java:554)
  at
 org.jaggeryjs.hostobjects.ws.WSRequestHostObject.jsFunction_send(WSRequestHostObject.java:362)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  at java.lang.reflect.Method.invoke(Method.java:606)
 at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:126)
  at org.mozilla.javascript.FunctionObject.call(FunctionObject.java:386)
 at org.mozilla.javascript.optimizer.OptRuntime.call1(OptRuntime.java:32)
  at
 org.jaggeryjs.rhino.ArtifactBuilder__1.c1._c_script_0(/ArtifactBuilder-1//ws-rxt.jag:16)
 at
 org.jaggeryjs.rhino.ArtifactBuilder__1.c1.call(/ArtifactBuilder-1//ws-rxt.jag)
  at
 org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:394)
 at org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:3091)
  at
 org.jaggeryjs.rhino.ArtifactBuilder__1.c1.call(/ArtifactBuilder-1//ws-rxt.jag)
 at
 org.jaggeryjs.rhino.ArtifactBuilder__1.c1.exec(/ArtifactBuilder-1//ws-rxt.jag)
  at
 org.jaggeryjs.scriptengine.engine.RhinoEngine.execScript(RhinoEngine.java:570)
 at org.jaggeryjs.scriptengine.engine.RhinoEngine.exec(RhinoEngine.java:273)
  at
 org.jaggeryjs.jaggery.core.manager.WebAppManager.execute(WebAppManager.java:432)
 at org.jaggeryjs.jaggery.core.JaggeryServlet.doPost(JaggeryServlet.java:29)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:755)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
  at
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
 at
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
  at
 org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:749)
 at
 org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:487)
  at
 org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:379)
 at
 org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:339)
  at
 org.jaggeryjs.jaggery.core.JaggeryFilter.doFilter(JaggeryFilter.java:21)
 at
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
  at
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
 at
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
  at
 org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
 at
 org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
  at
 

Re: [Dev] GSoC 2014 : Implement Registry Extension (RXT) 2.0 + Associated UI support

2014-08-11 Thread Shelan Perera
Hi Iresha,

Is there anything to be done at the server side or can we just save the
artifact in the UI? I got your new changes and deployed the app. But when i
try to save the
artifact i got the following error. Any idea on this ?. Have you committed
all your changes to the Git?


[2014-08-11 21:58:54,677]  INFO
{org.wso2.carbon.core.services.util.CarbonAuthenticationUtil} -
 'admin@carbon.super [-1234]' logged in at [2014-08-11 21:58:54,677+0530]
[2014-08-11 22:01:01,385]  INFO
{org.jaggeryjs.jaggery.app.mgt.TomcatJaggeryWebappsDeployer} -  Deployed
webapp:
StandardEngine[Catalina].StandardHost[localhost].StandardContext[/ArtifactBuilder-1].File[/home/shelan/wso2/gsoc-mentoring/wso2greg-4.6.0/repository/deployment/server/jaggeryapps/ArtifactBuilder-1]
[2014-08-11 22:02:36,008] ERROR
{org.jaggeryjs.hostobjects.ws.WSRequestHostObject} -  Error occured while
invoking the service
org.apache.axis2.AxisFault: The endpoint reference (EPR) for the Operation
not found is https://localhost:9443/services/ManageGenericArtifactService
and the WSA Action = urn:addJSONRXTResource. If this EPR was previously
reachable, please contact the server administrator.
 at
org.apache.axis2.util.Utils.getInboundFaultFromMessageContext(Utils.java:531)
at
org.apache.axis2.description.OutInAxisOperationClient.handleResponse(OutInAxisOperation.java:367)
 at
org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:413)
at
org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:224)
 at
org.apache.axis2.client.OperationClient.execute(OperationClient.java:149)
at org.apache.axis2.client.ServiceClient.sendReceive(ServiceClient.java:554)
 at
org.jaggeryjs.hostobjects.ws.WSRequestHostObject.jsFunction_send(WSRequestHostObject.java:362)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:606)
at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:126)
 at org.mozilla.javascript.FunctionObject.call(FunctionObject.java:386)
at org.mozilla.javascript.optimizer.OptRuntime.call1(OptRuntime.java:32)
 at
org.jaggeryjs.rhino.ArtifactBuilder__1.c1._c_script_0(/ArtifactBuilder-1//ws-rxt.jag:16)
at
org.jaggeryjs.rhino.ArtifactBuilder__1.c1.call(/ArtifactBuilder-1//ws-rxt.jag)
 at org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:394)
at org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:3091)
 at
org.jaggeryjs.rhino.ArtifactBuilder__1.c1.call(/ArtifactBuilder-1//ws-rxt.jag)
at
org.jaggeryjs.rhino.ArtifactBuilder__1.c1.exec(/ArtifactBuilder-1//ws-rxt.jag)
 at
org.jaggeryjs.scriptengine.engine.RhinoEngine.execScript(RhinoEngine.java:570)
at org.jaggeryjs.scriptengine.engine.RhinoEngine.exec(RhinoEngine.java:273)
 at
org.jaggeryjs.jaggery.core.manager.WebAppManager.execute(WebAppManager.java:432)
at org.jaggeryjs.jaggery.core.JaggeryServlet.doPost(JaggeryServlet.java:29)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:755)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
 at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
 at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:749)
at
org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:487)
 at
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:379)
at
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:339)
 at org.jaggeryjs.jaggery.core.JaggeryFilter.doFilter(JaggeryFilter.java:21)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
 at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
 at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
 at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
 at
org.wso2.carbon.tomcat.ext.valves.CompositeValve.continueInvocation(CompositeValve.java:178)
at
org.wso2.carbon.tomcat.ext.valves.CarbonTomcatValve$1.invoke(CarbonTomcatValve.java:47)
 at
org.wso2.carbon.webapp.mgt.TenantLazyLoaderValve.invoke(TenantLazyLoaderValve.java:56)
at
org.wso2.carbon.apimgt.interceptor.valve.APIManagerInterceptorValve.invoke(APIManagerInterceptorValve.java:120)
 at
org.wso2.carbon.tomcat.ext.valves.TomcatValveContainer.invokeValves(TomcatValveContainer.java:47)
at

Re: [Dev] GSoC 2014 : Implement Registry Extension (RXT) 2.0 + Associated UI support

2014-08-10 Thread Iresha Udayangani
Hi all,

During the last couple of weeks, I was able to achieve most of
the deliverables of the project.

Once the user is Logged in to Greg and go to the ArtifactBuilder Jaggery
Application, user is provided with a simple ui with drag and drop
functionality to input necessary parameters of the new RXT. Once user
clicks on 'Save Artifact', a basic client side validation will happen and a
JSON( with additional metadata) is generated using javascript. I have used
a Jaggery WS-Request to call the ManageGenericArtifact Admin Service and
send the generated JSON string to Greg side. I created a new method
'addJSONRXTResource' which will take care of converting the json to the
existing xml based rxt format and call the 'addRXTResource' method. This
will work without breaking the existing XML based RXT model. Since the JSON
is passed to the ManageGenericArtifactService, we can call a registry.put()
and save the json string as a file in the registry as well. I have attached
a simple screens-cast which demonstrates the above scenario.

*Commits*

Jaggery App : https://github.com/ireshapm0/ArtifactBuilder/commits/master
Carbon-governance :
https://github.com/ireshapm0/carbon-governance/commits/dev-rxt-json

*To-DOs*

Even though I've got a end-to-end working application, below are the tasks
which needs to be done to make the application finalized. I will try to
do at-least one of them within next week.

   - Multiple Table support for dynamic content section.
   - Minimize user input effort by adding auto complete data
   - Generate UI from RXT (reverse of what I have done so far)
   - Finalize content type fields and their usage.

Screen-cast :
https://drive.google.com/file/d/0B6jyof_EyG4hcGdfekpYY3dFT1U/edit?usp=sharing

Thanks,
Iresha



On Fri, Aug 1, 2014 at 5:57 PM, Shelan Perera she...@wso2.com wrote:

 Hi Iresha,

 Thanks for the updates. Looks good in progress. I have evaluated the code
 at Github and need to complete followings to complete the flow. Let me know
 if you have
 already completed them.

 1) XML generation from JSON to preserve backward compatibility for the
 moment and complete the existing flow.

 2) Adding JSON file to the Registry update with complete information. (To
 manage the information loss of existing XML schema)


 Thanks


 On Sun, Jul 27, 2014 at 6:49 PM, Iresha Udayangani iresh...@gmail.com
 wrote:

 Hi all,

 *Progress Update*

 (Project: Implement Registry Extension (RXT) 2.0 + Associated UI support )

 As I mentioned in my last update several issues were identified in the
 existing RXT /XML model. There were difficulties in rendering the UI (in
 ES) with the available information in the current RXT model. To overcome
 this drawback , it was decided to generate a JSON along with sufficient
 meta data, such that UI rendering can be done without much effort. And then
 XML which suits the existing model will generated from that JSON and used
 in the existing model.

 This update is on JSON generation and retrieving XML from JSON.

 I have committed the changes in git.

 https://github.com/ireshapm0/ArtifactBuilder/commit/master

 JSON is generated from UI in JavaScript and validation of mandatory
 fields is also done. Since the dynamic content components can keep much
 more meta data and all of them can be kept in JSON, UI rendering can be
 done without much effort as expected.

 I was able to generate XML from JSON, in java as well. The Jaggery App
 will send the JSON string to ManageGenericArifactService and JSON-XML
 generation will be done before calling addRXTResource().

 Yet I have to work on adding multiple tables in dynamic content section.
 And I hope to do those changes in coming weeks. I was trying to send the
 JSON to registry using a Jaggery call, but failed to get hold of the
 registry from Jaggery yet. Any help to do that will also be appreciated.

 Also I posted certain updates on my blog too.
 http://ireshapm.blogspot.com/


 Thanks.




 On Mon, Jun 23, 2014 at 12:38 AM, Shelan Perera she...@wso2.com wrote:

 Adding Eranda to this list too.

 Thanks


 On Mon, Jun 23, 2014 at 12:38 AM, Shelan Perera she...@wso2.com wrote:

 Hi Iresha,

  Looks like a good approach in overall. There are few enhancements we
 should do when progress.

 1) We should be able to hide/view RXT mandatory inputs area ( Now there
 is lot of prominenance for that area which makes drag/drop form designer to
 be restricted. ( Menu navigation on top bar would not be ideal, lets
 discuss this)

 2) We may need to optimize drag and drop area to give a consistent UI
 experience with existing UIs and we should work on that. (wording and the
 flow etc.)

 3)  I could observe that we are not using columns in RXT format. I hope
 that would be fine but lets come to a common agreement across teams whether
 to support it or not. (We saw that current Store service UI does not
 support it too.)

 In overall this is a good progress. Keep us updated and commit the code
 once you have improvements so we can 

Re: [Dev] GSoC 2014 : Implement Registry Extension (RXT) 2.0 + Associated UI support

2014-08-10 Thread Subash Chaturanga
Hi Iresha,

We are planning to push this to G-Reg 5.0.0. I believe we are supporting
everything that's there in the RXT schema. Correct me if I am wrong. And we
need to get this to improve (we don't expect that to be in your scope) to
support RXT inheritance UI model.

i.e - application rxt  attributes; name and version
 - mobile-application rxt  attributes; mobileType
- android application rxt  attributes; apkPath

Real RXT is android application. But some one can start defining an RXT
with the name and version and create a application RXT. Once he knows
mobile type and if android thr apk path he should be able to go to the
already defined application rxt and extend it to add mobile/android
attributes.

We need to make sure the current impl can be used and extend to achieve
what I aforementioned.

BTW Shelan, as soon as you come, let's have a meeting and review whats
done.

On Sun, Aug 10, 2014 at 7:59 PM, Iresha Udayangani iresh...@gmail.com
wrote:


 Hi all,

 During the last couple of weeks, I was able to achieve most of
 the deliverables of the project.

 Once the user is Logged in to Greg and go to the ArtifactBuilder Jaggery
 Application, user is provided with a simple ui with drag and drop
 functionality to input necessary parameters of the new RXT. Once user
 clicks on 'Save Artifact', a basic client side validation will happen and a
 JSON( with additional metadata) is generated using javascript. I have used
 a Jaggery WS-Request to call the ManageGenericArtifact Admin Service and
 send the generated JSON string to Greg side. I created a new method
 'addJSONRXTResource' which will take care of converting the json to the
 existing xml based rxt format and call the 'addRXTResource' method. This
 will work without breaking the existing XML based RXT model. Since the JSON
 is passed to the ManageGenericArtifactService, we can call a registry.put()
 and save the json string as a file in the registry as well. I have attached
 a simple screens-cast which demonstrates the above scenario.

 *Commits*

 Jaggery App : https://github.com/ireshapm0/ArtifactBuilder/commits/master
 Carbon-governance :
 https://github.com/ireshapm0/carbon-governance/commits/dev-rxt-json

 *To-DOs*

 Even though I've got a end-to-end working application, below are the tasks
 which needs to be done to make the application finalized. I will try to
 do at-least one of them within next week.

- Multiple Table support for dynamic content section.
- Minimize user input effort by adding auto complete data
- Generate UI from RXT (reverse of what I have done so far)


If you are creating the a deployable RXT xml from this UI, the reverse one
is already supported by ES. So in that sense you don't have to worry about
IMO. Shelan, please correct if I am missing something.


- Finalize content type fields and their usage.

 Screen-cast :
 https://drive.google.com/file/d/0B6jyof_EyG4hcGdfekpYY3dFT1U/edit?usp=sharing

 Thanks,
 Iresha



 On Fri, Aug 1, 2014 at 5:57 PM, Shelan Perera she...@wso2.com wrote:

 Hi Iresha,

 Thanks for the updates. Looks good in progress. I have evaluated the code
 at Github and need to complete followings to complete the flow. Let me know
 if you have
 already completed them.

 1) XML generation from JSON to preserve backward compatibility for the
 moment and complete the existing flow.

 2) Adding JSON file to the Registry update with complete information. (To
 manage the information loss of existing XML schema)


 Thanks


 On Sun, Jul 27, 2014 at 6:49 PM, Iresha Udayangani iresh...@gmail.com
 wrote:

 Hi all,

 *Progress Update*

 (Project: Implement Registry Extension (RXT) 2.0 + Associated UI support
 )

 As I mentioned in my last update several issues were identified in the
 existing RXT /XML model. There were difficulties in rendering the UI (in
 ES) with the available information in the current RXT model. To overcome
 this drawback , it was decided to generate a JSON along with sufficient
 meta data, such that UI rendering can be done without much effort. And then
 XML which suits the existing model will generated from that JSON and used
 in the existing model.

 This update is on JSON generation and retrieving XML from JSON.

 I have committed the changes in git.

 https://github.com/ireshapm0/ArtifactBuilder/commit/master

 JSON is generated from UI in JavaScript and validation of mandatory
 fields is also done. Since the dynamic content components can keep much
 more meta data and all of them can be kept in JSON, UI rendering can be
 done without much effort as expected.

 I was able to generate XML from JSON, in java as well. The Jaggery App
 will send the JSON string to ManageGenericArifactService and JSON-XML
 generation will be done before calling addRXTResource().

 Yet I have to work on adding multiple tables in dynamic content section.
 And I hope to do those changes in coming weeks. I was trying to send the
 JSON to registry using a Jaggery call, but failed to 

Re: [Dev] GSoC 2014 : Implement Registry Extension (RXT) 2.0 + Associated UI support

2014-08-01 Thread Shelan Perera
Hi Iresha,

Thanks for the updates. Looks good in progress. I have evaluated the code
at Github and need to complete followings to complete the flow. Let me know
if you have
already completed them.

1) XML generation from JSON to preserve backward compatibility for the
moment and complete the existing flow.

2) Adding JSON file to the Registry update with complete information. (To
manage the information loss of existing XML schema)


Thanks


On Sun, Jul 27, 2014 at 6:49 PM, Iresha Udayangani iresh...@gmail.com
wrote:

 Hi all,

 *Progress Update*

 (Project: Implement Registry Extension (RXT) 2.0 + Associated UI support )

 As I mentioned in my last update several issues were identified in the
 existing RXT /XML model. There were difficulties in rendering the UI (in
 ES) with the available information in the current RXT model. To overcome
 this drawback , it was decided to generate a JSON along with sufficient
 meta data, such that UI rendering can be done without much effort. And then
 XML which suits the existing model will generated from that JSON and used
 in the existing model.

 This update is on JSON generation and retrieving XML from JSON.

 I have committed the changes in git.

 https://github.com/ireshapm0/ArtifactBuilder/commit/master

 JSON is generated from UI in JavaScript and validation of mandatory fields
 is also done. Since the dynamic content components can keep much more meta
 data and all of them can be kept in JSON, UI rendering can be done without
 much effort as expected.

 I was able to generate XML from JSON, in java as well. The Jaggery App
 will send the JSON string to ManageGenericArifactService and JSON-XML
 generation will be done before calling addRXTResource().

 Yet I have to work on adding multiple tables in dynamic content section.
 And I hope to do those changes in coming weeks. I was trying to send the
 JSON to registry using a Jaggery call, but failed to get hold of the
 registry from Jaggery yet. Any help to do that will also be appreciated.

 Also I posted certain updates on my blog too.
 http://ireshapm.blogspot.com/


 Thanks.




 On Mon, Jun 23, 2014 at 12:38 AM, Shelan Perera she...@wso2.com wrote:

 Adding Eranda to this list too.

 Thanks


 On Mon, Jun 23, 2014 at 12:38 AM, Shelan Perera she...@wso2.com wrote:

 Hi Iresha,

  Looks like a good approach in overall. There are few enhancements we
 should do when progress.

 1) We should be able to hide/view RXT mandatory inputs area ( Now there
 is lot of prominenance for that area which makes drag/drop form designer to
 be restricted. ( Menu navigation on top bar would not be ideal, lets
 discuss this)

 2) We may need to optimize drag and drop area to give a consistent UI
 experience with existing UIs and we should work on that. (wording and the
 flow etc.)

 3)  I could observe that we are not using columns in RXT format. I hope
 that would be fine but lets come to a common agreement across teams whether
 to support it or not. (We saw that current Store service UI does not
 support it too.)

 In overall this is a good progress. Keep us updated and commit the code
 once you have improvements so we can test and understand your improvements.

 Thanks


 On Sat, Jun 21, 2014 at 11:48 AM, Iresha Udayangani iresh...@gmail.com
 wrote:

 Hi all,

 *Progress Update*

 (Project: Implement Registry Extension (RXT) 2.0 + Associated UI
 support - Updates and Notes)

 Please find an update of the project so far and the plan for the next
 couple of weeks. There was a slight change in the project scope since the
 JSON support for RXT was temporarily removed and the scope was narrowed
 down to creating a Jaggery app which could support creating a new artifact
 type with an intuitive drag and drop UI.


 I had a meeting with Shelan, Subash and Lasindu last week and below are
 the facts discussed.


- Finalized the requirement of a Jaggery app to create a new
artifact type which could be installed to either Greg or ES via 
 Management
Console

- RXT content should be generated using drag and drop components
and user shall be able to change the fields easily by dragging 
 components
here and there.

- The RXT XML should be generated in the client side using JS as
well as some metadata should be kept with UI fields in order for ES to
generate its ‘add metadata’ model.

- This model should also facilitate creating a JSON out of the UI,
at some point of time.

- Once the XML is generated, a backend call will be made to
Registry to add the RXT via Jaggery.


  *Current Progress*

 In the Process of finding a suitable plugin for drag and drop
 functionality, I was told that Gridster.js [1] was used in UES and is very
 flexible in generating UIs. But it seems to be bit difficult to use it in
 this purpose, since it needed a lot of fine tuning to be able to cater this
 requirement. I too found Bootsnipp Form Builder [2] which seems to be bit
 similar to the one which is 

Re: [Dev] GSoC 2014 : Implement Registry Extension (RXT) 2.0 + Associated UI support

2014-07-27 Thread Iresha Udayangani
Hi all,

*Progress Update*

(Project: Implement Registry Extension (RXT) 2.0 + Associated UI support )

As I mentioned in my last update several issues were identified in the
existing RXT /XML model. There were difficulties in rendering the UI (in
ES) with the available information in the current RXT model. To overcome
this drawback , it was decided to generate a JSON along with sufficient
meta data, such that UI rendering can be done without much effort. And then
XML which suits the existing model will generated from that JSON and used
in the existing model.

This update is on JSON generation and retrieving XML from JSON.

I have committed the changes in git.

https://github.com/ireshapm0/ArtifactBuilder/commit/master

JSON is generated from UI in JavaScript and validation of mandatory fields
is also done. Since the dynamic content components can keep much more meta
data and all of them can be kept in JSON, UI rendering can be done without
much effort as expected.

I was able to generate XML from JSON, in java as well. The Jaggery App will
send the JSON string to ManageGenericArifactService and JSON-XML
generation will be done before calling addRXTResource().

Yet I have to work on adding multiple tables in dynamic content section.
And I hope to do those changes in coming weeks. I was trying to send the
JSON to registry using a Jaggery call, but failed to get hold of the
registry from Jaggery yet. Any help to do that will also be appreciated.

Also I posted certain updates on my blog too. http://ireshapm.blogspot.com/


Thanks.




On Mon, Jun 23, 2014 at 12:38 AM, Shelan Perera she...@wso2.com wrote:

 Adding Eranda to this list too.

 Thanks


 On Mon, Jun 23, 2014 at 12:38 AM, Shelan Perera she...@wso2.com wrote:

 Hi Iresha,

  Looks like a good approach in overall. There are few enhancements we
 should do when progress.

 1) We should be able to hide/view RXT mandatory inputs area ( Now there
 is lot of prominenance for that area which makes drag/drop form designer to
 be restricted. ( Menu navigation on top bar would not be ideal, lets
 discuss this)

 2) We may need to optimize drag and drop area to give a consistent UI
 experience with existing UIs and we should work on that. (wording and the
 flow etc.)

 3)  I could observe that we are not using columns in RXT format. I hope
 that would be fine but lets come to a common agreement across teams whether
 to support it or not. (We saw that current Store service UI does not
 support it too.)

 In overall this is a good progress. Keep us updated and commit the code
 once you have improvements so we can test and understand your improvements.

 Thanks


 On Sat, Jun 21, 2014 at 11:48 AM, Iresha Udayangani iresh...@gmail.com
 wrote:

 Hi all,

 *Progress Update*

 (Project: Implement Registry Extension (RXT) 2.0 + Associated UI support
 - Updates and Notes)

 Please find an update of the project so far and the plan for the next
 couple of weeks. There was a slight change in the project scope since the
 JSON support for RXT was temporarily removed and the scope was narrowed
 down to creating a Jaggery app which could support creating a new artifact
 type with an intuitive drag and drop UI.


 I had a meeting with Shelan, Subash and Lasindu last week and below are
 the facts discussed.


- Finalized the requirement of a Jaggery app to create a new
artifact type which could be installed to either Greg or ES via 
 Management
Console

- RXT content should be generated using drag and drop components
and user shall be able to change the fields easily by dragging components
here and there.

- The RXT XML should be generated in the client side using JS as
well as some metadata should be kept with UI fields in order for ES to
generate its ‘add metadata’ model.

- This model should also facilitate creating a JSON out of the UI,
at some point of time.

- Once the XML is generated, a backend call will be made to Registry
to add the RXT via Jaggery.


  *Current Progress*

 In the Process of finding a suitable plugin for drag and drop
 functionality, I was told that Gridster.js [1] was used in UES and is very
 flexible in generating UIs. But it seems to be bit difficult to use it in
 this purpose, since it needed a lot of fine tuning to be able to cater this
 requirement. I too found Bootsnipp Form Builder [2] which seems to be bit
 similar to the one which is required under MIT license and built on
 bootstrap. So decided to go on with it.

 I was able to create a simple UI, create a Jaggery app and host it in
 Greg/ES and test the functionality. Below is a sample UI which has only the
 basic functionality to create a RXT.


 [image: japp.png]

 I was told several issues the existing RXT, XML model has and the
 difficulties in rendering the UI (in ES) only with the information it
 provides and necessity of keeping other metadata along with the xml model.
 So I’ working on a way to find out the best possible 

Re: [Dev] GSoC 2014 : Implement Registry Extension (RXT) 2.0 + Associated UI support

2014-04-26 Thread Iresha Udayangani
Hi Shelan,

First of all I would like to thank WSO2 team including you for helping me
out to get my proposal accepted for GSOC 2014. I am very glad to be a part
of WSO2 community and at the same time it is a pleasure to meet you as the
mentor of my GSoC project.

During the community bonding period I would like to discuss the project in
detail and the project scope. It would be great if you could give me a
possible time to have a meeting/chat to discuss on the project.

Also please let me know if there are any particular things to be done/read
in the meantime.

Thank you.
Iresha


On Wed, Mar 19, 2014 at 8:54 AM, Iresha Udayangani iresh...@gmail.comwrote:

 Hi all,

 I have published the proposal  at following URL:

 http://www.google-melange.com/gsoc/proposal/public/google/gsoc2014/ireshapm/5629499534213120

 I would appreciate if you could give some feedback, so that I can improve
 my proposal in the next couple of days.


 Thanks,
 Iresha


 On Fri, Mar 14, 2014 at 3:20 PM, Iresha Udayangani iresh...@gmail.comwrote:

 Hi Shelan,

 Thanks for the reply. I have updated the link in the document.

 Thanks,
 Iresha


 On Fri, Mar 14, 2014 at 3:04 PM, Shelan Perera she...@wso2.com wrote:

 Hi Iresha,

 This proposal looks good. Specially the UI proposed for RXT
 configuration is a huge usability improvement. Could you please add the
 sample JSON format you proposed in the mailing list to the proposal as well?

 Thanks


 On Fri, Mar 14, 2014 at 2:51 PM, Iresha Udayangani 
 iresh...@gmail.comwrote:

 Hi all,

 I have created a draft proposal for the project. Please find the
 document in [1]. It would be greatly helpful for me if you could provide me
 with some feedback so that I could improve it in next couple of days.

 [1]
 https://docs.google.com/document/d/1WzRicvDTOjINU4zm9txzJRpftF-Tfr_e6YezSHGtvkc/edit?usp=sharing

 Thanks,
 Iresha


 On Tue, Mar 11, 2014 at 9:24 PM, Iresha Udayangani 
 iresh...@gmail.comwrote:

 Hi all,

 Thank you for your replies. I was able to create a sample JSON file
 which can be used instead of the current XML file (attached). The
 current default rxt in the Artifact Source editor can be replaced by
 something similar to the above.

 I also went through org.wso2.carbon.governance.generic and
 org.wso2.carbon.governance.generic.ui components in governance and
 seems like it's the best starting point to look at the code. As far as
 I
 could understand, the java classes corresponding jsp files needs to be
 modified in order to facilitate using json instead of xml.

 The XML parsing done through axiom needs to be replaced by a new JSON
 parser. As mentioned in the [4] above, the new json based
 implementation could facilitate adding a new artifact type inside
 another artifact. I could understand how a new artifact can be added
 inside an existing json file of an artifact, but I'm not very much
 sure how to implement it in the code level.

 Please let me know what are the other aspects of the project which I
 could look at in order to get an overall idea of the project. I will
 upload a draft proposal in couple of days.

 Thanks,
 Iresha



 On Mon, Mar 10, 2014 at 7:39 AM, Eranda Sooriyabandara 
 era...@wso2.com wrote:

 Hi Iresha,
 The deliverables to this project would be,

 1. A jason configuration for replacing current RXT configuration model
 2. Plug that model to the existing UI generator model (This should be
 refactor or replace our old UI generator)
 3. Plug that model to the existing Governance API
 4. Implementing nested RXT support - Currently we only allow to have
 basic data support in field. But we need to improve this to define 
 another
 datatype inside a datatype. I'll explain this in detail later.

 thanks
 Eranda


 On Fri, Mar 7, 2014 at 11:01 AM, Iresha Udayangani 
 iresh...@gmail.com wrote:

 Hi all,


 I'm Iresha Udayangani, a 3rd year undergraduate of department of
 Electronic and Telecommunication Engineering, University of Moratuwa,
 Sri Lanka. I went through the list of WSO2 project ideas for GSOC

 2014. Proposal 1: Implement Registry Extension (RXT) 2.0 + Associated

 UI support seemed to be quite interesting and match my past
 experiences.

 I was able to download wso2greg-4.6.0, then run it. I went through
 some of the reference documents/webinars and uploaded a couple of rxt
 files(person.rxt, project.rxt) in Extensions-Artifact Types -Add
 new
 Artifacts and got familiar with their functionality.

 As far as I can understand the project expects the following,

 [1] A new RXT format should be defined using JSON, instead of the
 current XML Structure, so that existing JSPs might need few
 alterations in order to render UIs based on the new JSON format.
 JSON seems to be more efficient and browser friendly compared to XML.

 [2] Instead of user manually configuring/creating the XML structure
 (RXT definition) the project expects to automatically generate the
 RXT
 definition from a UI template.

 [3] When adding a new Artifact type, user can be 

Re: [Dev] GSoC 2014 : Implement Registry Extension (RXT) 2.0 + Associated UI support

2014-04-26 Thread Shelan Perera
Hi Iresha,

Congratulations for being accepted and welcome to the awesome world of GSoC
:).

At the moment i am out of the country and will be travelling next weekend
but We can have a meeting on 7th May . If you like to visit WSO2 and have
the meeting there we may be able get some of the other product members as
well. But  it is not required to visit and we may be able to have a Hangout
session if that is convenient.

Usually as the first step i would like you to start blogging about GSoC
experience. You may write all your experience not limiting to Technical
stuff but just as a journal which will be really helpful. You may use your
own personal blog or have another space but let it include the complete
GSoC journey.

Lets discuss the things in the next meeting.

Best Regards,



On Sat, Apr 26, 2014 at 4:00 PM, Iresha Udayangani iresh...@gmail.comwrote:

 Hi Shelan,

 First of all I would like to thank WSO2 team including you for helping me
 out to get my proposal accepted for GSOC 2014. I am very glad to be a part
 of WSO2 community and at the same time it is a pleasure to meet you as the
 mentor of my GSoC project.

 During the community bonding period I would like to discuss the project in
 detail and the project scope. It would be great if you could give me a
 possible time to have a meeting/chat to discuss on the project.

 Also please let me know if there are any particular things to be done/read
 in the meantime.

 Thank you.
 Iresha


 On Wed, Mar 19, 2014 at 8:54 AM, Iresha Udayangani iresh...@gmail.comwrote:

 Hi all,

 I have published the proposal  at following URL:

 http://www.google-melange.com/gsoc/proposal/public/google/gsoc2014/ireshapm/5629499534213120

 I would appreciate if you could give some feedback, so that I can improve
 my proposal in the next couple of days.


 Thanks,
 Iresha


 On Fri, Mar 14, 2014 at 3:20 PM, Iresha Udayangani iresh...@gmail.comwrote:

 Hi Shelan,

 Thanks for the reply. I have updated the link in the document.

 Thanks,
 Iresha


 On Fri, Mar 14, 2014 at 3:04 PM, Shelan Perera she...@wso2.com wrote:

 Hi Iresha,

 This proposal looks good. Specially the UI proposed for RXT
 configuration is a huge usability improvement. Could you please add the
 sample JSON format you proposed in the mailing list to the proposal as 
 well?

 Thanks


 On Fri, Mar 14, 2014 at 2:51 PM, Iresha Udayangani 
 iresh...@gmail.comwrote:

 Hi all,

 I have created a draft proposal for the project. Please find the
 document in [1]. It would be greatly helpful for me if you could provide 
 me
 with some feedback so that I could improve it in next couple of days.

 [1]
 https://docs.google.com/document/d/1WzRicvDTOjINU4zm9txzJRpftF-Tfr_e6YezSHGtvkc/edit?usp=sharing

 Thanks,
 Iresha


 On Tue, Mar 11, 2014 at 9:24 PM, Iresha Udayangani iresh...@gmail.com
  wrote:

 Hi all,

 Thank you for your replies. I was able to create a sample JSON file
 which can be used instead of the current XML file (attached). The
 current default rxt in the Artifact Source editor can be replaced by
 something similar to the above.

 I also went through org.wso2.carbon.governance.generic and
 org.wso2.carbon.governance.generic.ui components in governance and
 seems like it's the best starting point to look at the code. As far
 as I
 could understand, the java classes corresponding jsp files needs to be
 modified in order to facilitate using json instead of xml.

 The XML parsing done through axiom needs to be replaced by a new JSON
 parser. As mentioned in the [4] above, the new json based
 implementation could facilitate adding a new artifact type inside
 another artifact. I could understand how a new artifact can be added
 inside an existing json file of an artifact, but I'm not very much
 sure how to implement it in the code level.

 Please let me know what are the other aspects of the project which I
 could look at in order to get an overall idea of the project. I will
 upload a draft proposal in couple of days.

 Thanks,
 Iresha



 On Mon, Mar 10, 2014 at 7:39 AM, Eranda Sooriyabandara 
 era...@wso2.com wrote:

 Hi Iresha,
 The deliverables to this project would be,

 1. A jason configuration for replacing current RXT configuration
 model
 2. Plug that model to the existing UI generator model (This should
 be refactor or replace our old UI generator)
 3. Plug that model to the existing Governance API
 4. Implementing nested RXT support - Currently we only allow to have
 basic data support in field. But we need to improve this to define 
 another
 datatype inside a datatype. I'll explain this in detail later.

 thanks
 Eranda


 On Fri, Mar 7, 2014 at 11:01 AM, Iresha Udayangani 
 iresh...@gmail.com wrote:

 Hi all,


 I'm Iresha Udayangani, a 3rd year undergraduate of department of
 Electronic and Telecommunication Engineering, University of
 Moratuwa,
 Sri Lanka. I went through the list of WSO2 project ideas for GSOC

 2014. Proposal 1: Implement Registry Extension (RXT) 2.0 +
 Associated

 UI support 

Re: [Dev] GSoC 2014 : Implement Registry Extension (RXT) 2.0 + Associated UI support

2014-03-14 Thread Iresha Udayangani
Hi all,

I have created a draft proposal for the project. Please find the document
in [1]. It would be greatly helpful for me if you could provide me with
some feedback so that I could improve it in next couple of days.

[1]
https://docs.google.com/document/d/1WzRicvDTOjINU4zm9txzJRpftF-Tfr_e6YezSHGtvkc/edit?usp=sharing

Thanks,
Iresha


On Tue, Mar 11, 2014 at 9:24 PM, Iresha Udayangani iresh...@gmail.comwrote:

 Hi all,

 Thank you for your replies. I was able to create a sample JSON file
 which can be used instead of the current XML file (attached). The
 current default rxt in the Artifact Source editor can be replaced by
 something similar to the above.

 I also went through org.wso2.carbon.governance.generic and
 org.wso2.carbon.governance.generic.ui components in governance and
 seems like it's the best starting point to look at the code. As far as I
 could understand, the java classes corresponding jsp files needs to be
 modified in order to facilitate using json instead of xml.

 The XML parsing done through axiom needs to be replaced by a new JSON
 parser. As mentioned in the [4] above, the new json based
 implementation could facilitate adding a new artifact type inside
 another artifact. I could understand how a new artifact can be added
 inside an existing json file of an artifact, but I'm not very much
 sure how to implement it in the code level.

 Please let me know what are the other aspects of the project which I
 could look at in order to get an overall idea of the project. I will
 upload a draft proposal in couple of days.

 Thanks,
 Iresha



 On Mon, Mar 10, 2014 at 7:39 AM, Eranda Sooriyabandara era...@wso2.comwrote:

 Hi Iresha,
 The deliverables to this project would be,

 1. A jason configuration for replacing current RXT configuration model
 2. Plug that model to the existing UI generator model (This should be
 refactor or replace our old UI generator)
 3. Plug that model to the existing Governance API
 4. Implementing nested RXT support - Currently we only allow to have
 basic data support in field. But we need to improve this to define another
 datatype inside a datatype. I'll explain this in detail later.

 thanks
 Eranda


 On Fri, Mar 7, 2014 at 11:01 AM, Iresha Udayangani iresh...@gmail.comwrote:

 Hi all,


 I'm Iresha Udayangani, a 3rd year undergraduate of department of
 Electronic and Telecommunication Engineering, University of Moratuwa,
 Sri Lanka. I went through the list of WSO2 project ideas for GSOC

 2014. Proposal 1: Implement Registry Extension (RXT) 2.0 + Associated

 UI support seemed to be quite interesting and match my past
 experiences.

 I was able to download wso2greg-4.6.0, then run it. I went through
 some of the reference documents/webinars and uploaded a couple of rxt
 files(person.rxt, project.rxt) in Extensions-Artifact Types -Add new
 Artifacts and got familiar with their functionality.

 As far as I can understand the project expects the following,

 [1] A new RXT format should be defined using JSON, instead of the
 current XML Structure, so that existing JSPs might need few
 alterations in order to render UIs based on the new JSON format.
 JSON seems to be more efficient and browser friendly compared to XML.

 [2] Instead of user manually configuring/creating the XML structure
 (RXT definition) the project expects to automatically generate the RXT
 definition from a UI template.

 [3] When adding a new Artifact type, user can be provided with a new
 UI where it contains basic fields to be filled (such as artifactType,
 singularLabel, pluralLabel, storagePath etc. ) and few custom elements
 (to add UI columns, content fields) instead of the current XML editor,
 where user needs a bit of programming background to configure things.
 After the user successfully configured the new artifact, the RXT
 format can be generated using the information provided in the previous
 step. An editor can be provided  for the advanced users as well.

 I'm a bit struggling in understanding  some of the project
 deliverables and trying to find the code samples, where it needs to be
 modified. It would be much helpful if anyone could help me out with
 more details.

 Thanks,
 Iresha.

 ___
 Dev mailing list
 Dev@wso2.org
 http://wso2.org/cgi-bin/mailman/listinfo/dev




 --

 *Eranda Sooriyabandara*Senior Software Engineer;
 Integration Technologies Team;
 WSO2 Inc.; http://wso2.com
  Lean . Enterprise . Middleware

 E-mail: eranda AT wso2.com
 Mobile: +94 716 472 816
 Linked-In: http://www.linkedin.com/in/erandasooriyabandara
 Blog: http://emsooriyabandara.blogspot.com/







 --
 Iresha Udayangani
 Undergraduate ,
 Department of Electronic  Telecommunication,
 University Of Moratuwa.




-- 
Iresha Udayangani
Undergraduate ,
Department of Electronic  Telecommunication,
University Of Moratuwa.
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev


Re: [Dev] GSoC 2014 : Implement Registry Extension (RXT) 2.0 + Associated UI support

2014-03-14 Thread Shelan Perera
Hi Iresha,

This proposal looks good. Specially the UI proposed for RXT configuration
is a huge usability improvement. Could you please add the sample JSON
format you proposed in the mailing list to the proposal as well?

Thanks


On Fri, Mar 14, 2014 at 2:51 PM, Iresha Udayangani iresh...@gmail.comwrote:

 Hi all,

 I have created a draft proposal for the project. Please find the document
 in [1]. It would be greatly helpful for me if you could provide me with
 some feedback so that I could improve it in next couple of days.

 [1]
 https://docs.google.com/document/d/1WzRicvDTOjINU4zm9txzJRpftF-Tfr_e6YezSHGtvkc/edit?usp=sharing

 Thanks,
 Iresha


 On Tue, Mar 11, 2014 at 9:24 PM, Iresha Udayangani iresh...@gmail.comwrote:

 Hi all,

 Thank you for your replies. I was able to create a sample JSON file
 which can be used instead of the current XML file (attached). The
 current default rxt in the Artifact Source editor can be replaced by
 something similar to the above.

 I also went through org.wso2.carbon.governance.generic and
 org.wso2.carbon.governance.generic.ui components in governance and
 seems like it's the best starting point to look at the code. As far as I
 could understand, the java classes corresponding jsp files needs to be
 modified in order to facilitate using json instead of xml.

 The XML parsing done through axiom needs to be replaced by a new JSON
 parser. As mentioned in the [4] above, the new json based
 implementation could facilitate adding a new artifact type inside
 another artifact. I could understand how a new artifact can be added
 inside an existing json file of an artifact, but I'm not very much
 sure how to implement it in the code level.

 Please let me know what are the other aspects of the project which I
 could look at in order to get an overall idea of the project. I will
 upload a draft proposal in couple of days.

 Thanks,
 Iresha



 On Mon, Mar 10, 2014 at 7:39 AM, Eranda Sooriyabandara 
 era...@wso2.comwrote:

 Hi Iresha,
 The deliverables to this project would be,

 1. A jason configuration for replacing current RXT configuration model
 2. Plug that model to the existing UI generator model (This should be
 refactor or replace our old UI generator)
 3. Plug that model to the existing Governance API
 4. Implementing nested RXT support - Currently we only allow to have
 basic data support in field. But we need to improve this to define another
 datatype inside a datatype. I'll explain this in detail later.

 thanks
 Eranda


 On Fri, Mar 7, 2014 at 11:01 AM, Iresha Udayangani 
 iresh...@gmail.comwrote:

 Hi all,


 I'm Iresha Udayangani, a 3rd year undergraduate of department of
 Electronic and Telecommunication Engineering, University of Moratuwa,
 Sri Lanka. I went through the list of WSO2 project ideas for GSOC

 2014. Proposal 1: Implement Registry Extension (RXT) 2.0 + Associated

 UI support seemed to be quite interesting and match my past
 experiences.

 I was able to download wso2greg-4.6.0, then run it. I went through
 some of the reference documents/webinars and uploaded a couple of rxt
 files(person.rxt, project.rxt) in Extensions-Artifact Types -Add new
 Artifacts and got familiar with their functionality.

 As far as I can understand the project expects the following,

 [1] A new RXT format should be defined using JSON, instead of the
 current XML Structure, so that existing JSPs might need few
 alterations in order to render UIs based on the new JSON format.
 JSON seems to be more efficient and browser friendly compared to XML.

 [2] Instead of user manually configuring/creating the XML structure
 (RXT definition) the project expects to automatically generate the RXT
 definition from a UI template.

 [3] When adding a new Artifact type, user can be provided with a new
 UI where it contains basic fields to be filled (such as artifactType,
 singularLabel, pluralLabel, storagePath etc. ) and few custom elements
 (to add UI columns, content fields) instead of the current XML editor,
 where user needs a bit of programming background to configure things.
 After the user successfully configured the new artifact, the RXT
 format can be generated using the information provided in the previous
 step. An editor can be provided  for the advanced users as well.

 I'm a bit struggling in understanding  some of the project
 deliverables and trying to find the code samples, where it needs to be
 modified. It would be much helpful if anyone could help me out with
 more details.

 Thanks,
 Iresha.

 ___
 Dev mailing list
 Dev@wso2.org
 http://wso2.org/cgi-bin/mailman/listinfo/dev




 --

 *Eranda Sooriyabandara*Senior Software Engineer;
 Integration Technologies Team;
 WSO2 Inc.; http://wso2.com
  Lean . Enterprise . Middleware

 E-mail: eranda AT wso2.com
 Mobile: +94 716 472 816
 Linked-In: http://www.linkedin.com/in/erandasooriyabandara
 Blog: http://emsooriyabandara.blogspot.com/







 --
 Iresha Udayangani
 

Re: [Dev] GSoC 2014 : Implement Registry Extension (RXT) 2.0 + Associated UI support

2014-03-14 Thread Iresha Udayangani
Hi Shelan,

Thanks for the reply. I have updated the link in the document.

Thanks,
Iresha


On Fri, Mar 14, 2014 at 3:04 PM, Shelan Perera she...@wso2.com wrote:

 Hi Iresha,

 This proposal looks good. Specially the UI proposed for RXT configuration
 is a huge usability improvement. Could you please add the sample JSON
 format you proposed in the mailing list to the proposal as well?

 Thanks


 On Fri, Mar 14, 2014 at 2:51 PM, Iresha Udayangani iresh...@gmail.comwrote:

 Hi all,

 I have created a draft proposal for the project. Please find the document
 in [1]. It would be greatly helpful for me if you could provide me with
 some feedback so that I could improve it in next couple of days.

 [1]
 https://docs.google.com/document/d/1WzRicvDTOjINU4zm9txzJRpftF-Tfr_e6YezSHGtvkc/edit?usp=sharing

 Thanks,
 Iresha


 On Tue, Mar 11, 2014 at 9:24 PM, Iresha Udayangani iresh...@gmail.comwrote:

 Hi all,

 Thank you for your replies. I was able to create a sample JSON file
 which can be used instead of the current XML file (attached). The
 current default rxt in the Artifact Source editor can be replaced by
 something similar to the above.

 I also went through org.wso2.carbon.governance.generic and
 org.wso2.carbon.governance.generic.ui components in governance and
 seems like it's the best starting point to look at the code. As far as I
 could understand, the java classes corresponding jsp files needs to be
 modified in order to facilitate using json instead of xml.

 The XML parsing done through axiom needs to be replaced by a new JSON
 parser. As mentioned in the [4] above, the new json based
 implementation could facilitate adding a new artifact type inside
 another artifact. I could understand how a new artifact can be added
 inside an existing json file of an artifact, but I'm not very much
 sure how to implement it in the code level.

 Please let me know what are the other aspects of the project which I
 could look at in order to get an overall idea of the project. I will
 upload a draft proposal in couple of days.

 Thanks,
 Iresha



 On Mon, Mar 10, 2014 at 7:39 AM, Eranda Sooriyabandara 
 era...@wso2.comwrote:

 Hi Iresha,
 The deliverables to this project would be,

 1. A jason configuration for replacing current RXT configuration model
 2. Plug that model to the existing UI generator model (This should be
 refactor or replace our old UI generator)
 3. Plug that model to the existing Governance API
 4. Implementing nested RXT support - Currently we only allow to have
 basic data support in field. But we need to improve this to define another
 datatype inside a datatype. I'll explain this in detail later.

 thanks
 Eranda


 On Fri, Mar 7, 2014 at 11:01 AM, Iresha Udayangani 
 iresh...@gmail.comwrote:

 Hi all,


 I'm Iresha Udayangani, a 3rd year undergraduate of department of
 Electronic and Telecommunication Engineering, University of Moratuwa,
 Sri Lanka. I went through the list of WSO2 project ideas for GSOC

 2014. Proposal 1: Implement Registry Extension (RXT) 2.0 + Associated

 UI support seemed to be quite interesting and match my past
 experiences.

 I was able to download wso2greg-4.6.0, then run it. I went through
 some of the reference documents/webinars and uploaded a couple of rxt
 files(person.rxt, project.rxt) in Extensions-Artifact Types -Add new
 Artifacts and got familiar with their functionality.

 As far as I can understand the project expects the following,

 [1] A new RXT format should be defined using JSON, instead of the
 current XML Structure, so that existing JSPs might need few
 alterations in order to render UIs based on the new JSON format.
 JSON seems to be more efficient and browser friendly compared to XML.

 [2] Instead of user manually configuring/creating the XML structure
 (RXT definition) the project expects to automatically generate the RXT
 definition from a UI template.

 [3] When adding a new Artifact type, user can be provided with a new
 UI where it contains basic fields to be filled (such as artifactType,
 singularLabel, pluralLabel, storagePath etc. ) and few custom elements
 (to add UI columns, content fields) instead of the current XML editor,
 where user needs a bit of programming background to configure things.
 After the user successfully configured the new artifact, the RXT
 format can be generated using the information provided in the previous
 step. An editor can be provided  for the advanced users as well.

 I'm a bit struggling in understanding  some of the project
 deliverables and trying to find the code samples, where it needs to be
 modified. It would be much helpful if anyone could help me out with
 more details.

 Thanks,
 Iresha.

 ___
 Dev mailing list
 Dev@wso2.org
 http://wso2.org/cgi-bin/mailman/listinfo/dev




 --

 *Eranda Sooriyabandara*Senior Software Engineer;
 Integration Technologies Team;
 WSO2 Inc.; http://wso2.com
  Lean . Enterprise . Middleware

 E-mail: eranda AT wso2.com
 

Re: [Dev] GSoC 2014 : Implement Registry Extension (RXT) 2.0 + Associated UI support

2014-03-11 Thread Iresha Udayangani
Hi all,

Thank you for your replies. I was able to create a sample JSON file
which can be used instead of the current XML file (attached). The
current default rxt in the Artifact Source editor can be replaced by
something similar to the above.

I also went through org.wso2.carbon.governance.generic and
org.wso2.carbon.governance.generic.ui components in governance and
seems like it's the best starting point to look at the code. As far as I
could understand, the java classes corresponding jsp files needs to be
modified in order to facilitate using json instead of xml.

The XML parsing done through axiom needs to be replaced by a new JSON
parser. As mentioned in the [4] above, the new json based
implementation could facilitate adding a new artifact type inside
another artifact. I could understand how a new artifact can be added
inside an existing json file of an artifact, but I'm not very much
sure how to implement it in the code level.

Please let me know what are the other aspects of the project which I
could look at in order to get an overall idea of the project. I will
upload a draft proposal in couple of days.

Thanks,
Iresha



On Mon, Mar 10, 2014 at 7:39 AM, Eranda Sooriyabandara era...@wso2.comwrote:

 Hi Iresha,
 The deliverables to this project would be,

 1. A jason configuration for replacing current RXT configuration model
 2. Plug that model to the existing UI generator model (This should be
 refactor or replace our old UI generator)
 3. Plug that model to the existing Governance API
 4. Implementing nested RXT support - Currently we only allow to have basic
 data support in field. But we need to improve this to define another
 datatype inside a datatype. I'll explain this in detail later.

 thanks
 Eranda


 On Fri, Mar 7, 2014 at 11:01 AM, Iresha Udayangani iresh...@gmail.comwrote:

 Hi all,


 I'm Iresha Udayangani, a 3rd year undergraduate of department of
 Electronic and Telecommunication Engineering, University of Moratuwa,
 Sri Lanka. I went through the list of WSO2 project ideas for GSOC

 2014. Proposal 1: Implement Registry Extension (RXT) 2.0 + Associated

 UI support seemed to be quite interesting and match my past
 experiences.

 I was able to download wso2greg-4.6.0, then run it. I went through
 some of the reference documents/webinars and uploaded a couple of rxt
 files(person.rxt, project.rxt) in Extensions-Artifact Types -Add new
 Artifacts and got familiar with their functionality.

 As far as I can understand the project expects the following,

 [1] A new RXT format should be defined using JSON, instead of the
 current XML Structure, so that existing JSPs might need few
 alterations in order to render UIs based on the new JSON format.
 JSON seems to be more efficient and browser friendly compared to XML.

 [2] Instead of user manually configuring/creating the XML structure
 (RXT definition) the project expects to automatically generate the RXT
 definition from a UI template.

 [3] When adding a new Artifact type, user can be provided with a new
 UI where it contains basic fields to be filled (such as artifactType,
 singularLabel, pluralLabel, storagePath etc. ) and few custom elements
 (to add UI columns, content fields) instead of the current XML editor,
 where user needs a bit of programming background to configure things.
 After the user successfully configured the new artifact, the RXT
 format can be generated using the information provided in the previous
 step. An editor can be provided  for the advanced users as well.

 I'm a bit struggling in understanding  some of the project
 deliverables and trying to find the code samples, where it needs to be
 modified. It would be much helpful if anyone could help me out with
 more details.

 Thanks,
 Iresha.

 ___
 Dev mailing list
 Dev@wso2.org
 http://wso2.org/cgi-bin/mailman/listinfo/dev




 --

 *Eranda Sooriyabandara*Senior Software Engineer;
 Integration Technologies Team;
 WSO2 Inc.; http://wso2.com
  Lean . Enterprise . Middleware

 E-mail: eranda AT wso2.com
 Mobile: +94 716 472 816
 Linked-In: http://www.linkedin.com/in/erandasooriyabandara
 Blog: http://emsooriyabandara.blogspot.com/







-- 
Iresha Udayangani
Undergraduate ,
Department of Electronic  Telecommunication,
University Of Moratuwa.


Enterprise Application.rxt
Description: Binary data
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev


Re: [Dev] GSoC 2014 : Implement Registry Extension (RXT) 2.0 + Associated UI support

2014-03-09 Thread Eranda Sooriyabandara
Hi Iresha,
The deliverables to this project would be,

1. A jason configuration for replacing current RXT configuration model
2. Plug that model to the existing UI generator model (This should be
refactor or replace our old UI generator)
3. Plug that model to the existing Governance API
4. Implementing nested RXT support - Currently we only allow to have basic
data support in field. But we need to improve this to define another
datatype inside a datatype. I'll explain this in detail later.

thanks
Eranda


On Fri, Mar 7, 2014 at 11:01 AM, Iresha Udayangani iresh...@gmail.comwrote:

 Hi all,


 I'm Iresha Udayangani, a 3rd year undergraduate of department of
 Electronic and Telecommunication Engineering, University of Moratuwa,
 Sri Lanka. I went through the list of WSO2 project ideas for GSOC

 2014. Proposal 1: Implement Registry Extension (RXT) 2.0 + Associated

 UI support seemed to be quite interesting and match my past
 experiences.

 I was able to download wso2greg-4.6.0, then run it. I went through
 some of the reference documents/webinars and uploaded a couple of rxt
 files(person.rxt, project.rxt) in Extensions-Artifact Types -Add new
 Artifacts and got familiar with their functionality.

 As far as I can understand the project expects the following,

 [1] A new RXT format should be defined using JSON, instead of the
 current XML Structure, so that existing JSPs might need few
 alterations in order to render UIs based on the new JSON format.
 JSON seems to be more efficient and browser friendly compared to XML.

 [2] Instead of user manually configuring/creating the XML structure
 (RXT definition) the project expects to automatically generate the RXT
 definition from a UI template.

 [3] When adding a new Artifact type, user can be provided with a new
 UI where it contains basic fields to be filled (such as artifactType,
 singularLabel, pluralLabel, storagePath etc. ) and few custom elements
 (to add UI columns, content fields) instead of the current XML editor,
 where user needs a bit of programming background to configure things.
 After the user successfully configured the new artifact, the RXT
 format can be generated using the information provided in the previous
 step. An editor can be provided  for the advanced users as well.

 I'm a bit struggling in understanding  some of the project
 deliverables and trying to find the code samples, where it needs to be
 modified. It would be much helpful if anyone could help me out with
 more details.

 Thanks,
 Iresha.

 ___
 Dev mailing list
 Dev@wso2.org
 http://wso2.org/cgi-bin/mailman/listinfo/dev




-- 

*Eranda Sooriyabandara*Senior Software Engineer;
Integration Technologies Team;
WSO2 Inc.; http://wso2.com
Lean . Enterprise . Middleware

E-mail: eranda AT wso2.com
Mobile: +94 716 472 816
Linked-In: http://www.linkedin.com/in/erandasooriyabandara
Blog: http://emsooriyabandara.blogspot.com/
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev


[Dev] GSoC 2014 : Implement Registry Extension (RXT) 2.0 + Associated UI support

2014-03-06 Thread Iresha Udayangani
Hi all,


I'm Iresha Udayangani, a 3rd year undergraduate of department of
Electronic and Telecommunication Engineering, University of Moratuwa,
Sri Lanka. I went through the list of WSO2 project ideas for GSOC

2014. Proposal 1: Implement Registry Extension (RXT) 2.0 + Associated

UI support seemed to be quite interesting and match my past
experiences.

I was able to download wso2greg-4.6.0, then run it. I went through
some of the reference documents/webinars and uploaded a couple of rxt
files(person.rxt, project.rxt) in Extensions-Artifact Types -Add new
Artifacts and got familiar with their functionality.

As far as I can understand the project expects the following,

[1] A new RXT format should be defined using JSON, instead of the
current XML Structure, so that existing JSPs might need few
alterations in order to render UIs based on the new JSON format.
JSON seems to be more efficient and browser friendly compared to XML.

[2] Instead of user manually configuring/creating the XML structure
(RXT definition) the project expects to automatically generate the RXT
definition from a UI template.

[3] When adding a new Artifact type, user can be provided with a new
UI where it contains basic fields to be filled (such as artifactType,
singularLabel, pluralLabel, storagePath etc. ) and few custom elements
(to add UI columns, content fields) instead of the current XML editor,
where user needs a bit of programming background to configure things.
After the user successfully configured the new artifact, the RXT
format can be generated using the information provided in the previous
step. An editor can be provided  for the advanced users as well.

I'm a bit struggling in understanding  some of the project
deliverables and trying to find the code samples, where it needs to be
modified. It would be much helpful if anyone could help me out with
more details.

Thanks,
Iresha.
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev