As a part of the unified governance work I'd like to re-think RXTs .. :). RXTs currently serve two purposes: - define the data model for particular registry extension (aka a metadata type (??)) - provide a way to automatically generate a reasonable user experience for editing instances of these things
I think we made a mistake in trying to do both at once. We meant to solve this in RXT 2.0 but never quite got to it. I'm proposing we do it now. Fundamentally, I see the media type definition as being the primal thing in defining the representation of an object of that type. So if you know the media type you can render or do whatever .. if you don't know it you're SOL. Sanjiva. On Fri, Aug 8, 2014 at 6:24 PM, Sameera Medagammaddegedara < [email protected]> wrote: > 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 > > -- Sanjiva Weerawarana, Ph.D. Founder, Chairman & CEO; WSO2, Inc.; http://wso2.com/ email: [email protected]; office: (+1 650 745 4499 | +94 11 214 5345) x5700; cell: +94 77 787 6880 | +1 408 466 5099; voip: +1 650 265 8311 blog: http://sanjiva.weerawarana.org/; twitter: @sanjiva Lean . Enterprise . Middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
