Hi,
This seems to mirror the functionality offered by the ES Publisher.
As the first phase we will extend our model to support app type specific
> RXTs, such that different app types will have different RXTs. The media
> type of the RXT will be based on the app type. When RXT Inheritance model
> is available, we are going to use it with a super parent app type RXT that
> every app type RXT should inherited from.
- All assets available in the store are based on a rxt
As the second phase we will focus on dynamically generate UI based on the
> app type. We will use the app type specific RXTs to get the metadata and
> the fields.
>
- All ES Publisher UIs are generated dynamically based on the RXT
definition
As the last phase we will move this concept and implementation to a unified
> governance model which will be a thin wrapper across
> GenericArtifactManager that can be used by all who needs to get info
> about applications.
>
- There is an existing jaggery module that wraps the functionality of
the GenericArtifactManager (carbon module)
- The app type extension model in the ES Publisher allows individual
asset types to override it
Let tenant admins to add apptype.jagg file which specify the UI components
> according to the RXT, when they are adding a app type. When a user selects
> a app type, content of the corresponding apptype.jagg will be loaded on the
> app creation page.
>
- We keep all asset type specific resources in an
extensions/assets/{type} directory (super tenant)
- This directory has a single asset.js file which defines a set of hooks
(asset create/update,search, lifecycle change,etc)
- The asset.js file is stored in the registry for each asset type on a
per tenant basis in the registry
If we are doing UI generator I would prefer to reuse it. But I feel with
> all the designing and different fields types (for example pick a
> Certificate file for apk and do valuations) it is far more cleaner and
> extensible from AF to ask the AppType writer to write the create.jag for
> their application.
>
>
- The asset.js script has two mechanisms to deal with this:
- A configure callback which can be used to change rxt field
properties
- A set of callbacks that are invoked prior to rendering the
create,update,list,search and lifecycle UIs
Thank You,
Sameera
On Fri, Aug 8, 2014 at 5:48 PM, Amila Maha Arachchi <[email protected]> wrote:
> Where are we going to place this jagg file (apptype.jag) ? According to
> Samith's mail, AFAIU this can be added by tenant admins.
>
>
> On Fri, Aug 8, 2014 at 4:31 PM, Dimuthu Leelarathne <[email protected]>
> wrote:
>
>>
>>
>>
>> On Fri, Aug 8, 2014 at 3:43 PM, Manuranga Perera <[email protected]> wrote:
>>
>>> ES already has a UI generator for RXT. is it possible to reuse it here ?
>>>
>>
>> If we are doing UI generator I would prefer to reuse it. But I feel with
>> all the designing and different fields types (for example pick a
>> Certificate file for apk and do valuations) it is far more cleaner and
>> extensible from AF to ask the AppType writer to write the create.jag for
>> their application.
>>
>> WDYT?
>>
>> thanks
>> dimuthu
>>
>>
>>>
>>> On Thu, Aug 7, 2014 at 5:01 PM, Samith Dassanayake <[email protected]>
>>> wrote:
>>>
>>>> Hi all,
>>>> For the dynamically generated UI part, two options have been considered
>>>>
>>>> 1. Let tenant admins to add apptype.jagg file which specify the UI
>>>> components according to the RXT, when they are adding a app type. When a
>>>> user selects a app type, content of the corresponding apptype.jagg will
>>>> be
>>>> loaded on the app creation page.
>>>> 2. Generate the UI from the RXT content by implementing a generic
>>>> UI loader.
>>>>
>>>> We are planing to move on with first option. WDYT?
>>>>
>>>>
>>>> On Thu, Aug 7, 2014 at 12:49 PM, Samith Dassanayake <[email protected]>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>> I have started working on the $subject[1] and it will be done in two
>>>>> phases
>>>>>
>>>>> In current implementation since we allow only pre-defined app
>>>>> types(Namely JAX-WS, JAX-RS, WAR, Data Service and Jaggery apps), we
>>>>> have only one generic RXT to capture application related information, for
>>>>> all the application types. As a new requirement since BYOAT(such as mobile
>>>>> apps, NodeJs etc.. ) came into play, we have decided to extend our model
>>>>> by
>>>>> providing the ability to add app type specific RXTs to app factory and
>>>>> dynamically generate the UI for applications based on the App type
>>>>> specific
>>>>> RXT.
>>>>>
>>>>> We are planing to achieve this in three phases.
>>>>>
>>>>> 1. As the first phase we will extend our model to support app type
>>>>> specific RXTs, such that different app types will have different RXTs.
>>>>> The
>>>>> media type of the RXT will be based on the app type. When RXT
>>>>> Inheritance
>>>>> model is available, we are going to use it with a super parent app
>>>>> type RXT
>>>>> that every app type RXT should inherited from.
>>>>> 2. As the second phase we will focus on dynamically generate UI
>>>>> based on the app type. We will use the app type specific RXTs to get
>>>>> the
>>>>> metadata and the fields.
>>>>> 3. As the last phase we will move this concept and implementation
>>>>> to a unified governance model which will be a thin wrapper across
>>>>> GenericArtifactManager that can be used by all who needs to get
>>>>> info about applications.
>>>>>
>>>>>
>>>>> [1] https://redmine.wso2.com/issues/2668
>>>>>
>>>>> Thank you
>>>>>
>>>>> --
>>>>> Best Regards
>>>>>
>>>>> Samith Dassanayake
>>>>> Software Engineer, WSO2 Inc.
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Best Regards
>>>>
>>>> Samith Dassanayake
>>>> Software Engineer, WSO2 Inc.
>>>>
>>>>
>>>> _______________________________________________
>>>> Architecture mailing list
>>>> [email protected]
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>>
>>> --
>>> With regards,
>>> *Manu*ranga Perera.
>>>
>>> phone : 071 7 70 20 50
>>> mail : [email protected]
>>>
>>> _______________________________________________
>>> Architecture mailing list
>>> [email protected]
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Dimuthu Leelarathne
>> Architect & Product Lead of App Factory
>>
>> WSO2, Inc. (http://wso2.com)
>> email: [email protected]
>> Mobile : 0773661935
>>
>> Lean . Enterprise . Middleware
>>
>> _______________________________________________
>> Architecture mailing list
>> [email protected]
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> *Amila Maharachchi*
> Senior Technical Lead
> WSO2, Inc.; http://wso2.com
>
> Blog: http://maharachchi.blogspot.com
> Mobile: +94719371446
>
>
> _______________________________________________
> Architecture mailing list
> [email protected]
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
--
Sameera Medagammaddegedara
Software Engineer
Contact:
Email: [email protected]
Mobile: + 94 077 255 3005
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
