Looking at the product, I see that I was wrong about this being something that can be done in Greg extension, necessary information has to be added in ES layer. But still effort shouldn't be high, because we can re-use same code. We just have to copy the same json object creation code from publisher to store side as well.
Anyway, the field rendering mechanism as it exist publisher today, is too limited. Because this one main places that customers ask to extend, and currently there is no way to extend it without overriding the whole thing, we may need to consider a extension strategy for this part. On Mon, Feb 8, 2016 at 1:37 PM, Sagara Gunathunga <[email protected]> wrote: > > > On Sat, Feb 6, 2016 at 9:48 PM, Ayesha Dissanayaka <[email protected]> > wrote: > >> Hi All, >> >> As of now with the information in the page object that comes into the >> relevant page rendering partials are not enough to implement a generic >> template in-order to organize options-text and unbounded table fields in >> the UI. >> >> Although, we can override partials via asset-type extensions knowing the >> page object (which comes to details page) content based on the rxt, it is >> not an optimal solution. Because, it will be rxt specific, non reusable and >> should be repeatedly extended for all the rxt types. Still, page object >> information are not organized enough to identify unbounded table headings, >> subheading and table fields separately. >> >> In publisher details page, input page object is constructed using render >> method >> in [1] and it is combined with RXT. It clearly has the RXT table structure >> of asset details. >> >> In store details page, input page object is constructed using renderBasic >> method in [2] and it is NOT combined with RXT. Hence, asset details come >> as a flat object. >> >> Based on above, I suggest that we pass same page details to store-details >> page as to publisher-details page. Then implement generic Helpers to render >> option-text and unbounded table, while giving extension points to use them >> in partials in order to enable show them UI. >> >> Once we make this change, there will be changes we might need to consider >> in existing partials. And we will need to do thorough testing to make sure >> nothing will break. >> > > @Ayesha, Do you have an idea about the effort required for above changes > ? > > If I'm not mistaken during the last ES/GS strategy meeting Manu mention > that displaying multiple ( not limited to name-version) RXT attributes at > the Store is even possible today but we just haven't use it, may be he can > shed some light here. > > According to my POV this is the expectation from users. > > Publisher - View and edit all RXT attributes based on logged-in user > permission. > > Store - Admin/Manager should able to configure what attributes > should be displayed on Store page in a per RXT type basic. Simply > displaying 2 attributes or displaying all RXT is not right IMO. > > Thanks ! > > > >> >> [1] >> https://github.com/wso2/carbon-store/blob/69cf234f70edf43dea3e41dbbd40a142c82deb84/jaggery-modules/rxt/module/scripts/asset/asset.js#L1811 >> [2] >> https://github.com/wso2/carbon-store/blob/69cf234f70edf43dea3e41dbbd40a142c82deb84/jaggery-modules/rxt/module/scripts/asset/asset.js#L1865 >> >> Thanks, >> -Ayesha >> >> On Fri, Feb 5, 2016 at 11:23 AM, Chandana Napagoda <[email protected]> >> wrote: >> >>> Hi All, >>> >>> Currently, we are displaying all the asset level fields (attributes) on >>> the publisher side, and version and name attribute only in the Store. The >>> decision to display all the of the available fields in the Store asset >>> details page depends on the end user business requirements. In most of the >>> cases, users can add more fields by customizing the relevant template >>> files. In such cases, end users may need to display information stored in >>> option-text and unbounded tables. >>> >>> However, we have identified an issue with the current implementation >>> which makes it difficult to render option-text and unbounded table related >>> data in the Store view. Ayesha has started investigating this issue and as >>> per the current findings this will involve a significant effort to >>> achieve. Ayesha can provide more insight on this. >>> >>> Regards, >>> Chandana >>> >>> -- >>> *Chandana Napagoda* >>> Senior Software Engineer >>> WSO2 Inc. - http://wso2.org >>> >>> *Email : [email protected] <[email protected]>**Mobile : +94718169299 >>> <%2B94718169299>* >>> >>> *Blog : http://cnapagoda.blogspot.com >>> <http://cnapagoda.blogspot.com>* >>> >>> >> >> >> -- >> *Ayesha Dissanayaka* >> Software Engineer, >> WSO2, Inc : http://wso2.com >> <http://www.google.com/url?q=http%3A%2F%2Fwso2.com&sa=D&sntz=1&usg=AFQjCNEZvyc0uMD1HhBaEGCBxs6e9fBObg> >> 20, Palmgrove Avenue, Colombo 3 >> E-Mail: [email protected] <[email protected]> >> > > > > -- > Sagara Gunathunga > > Architect; WSO2, Inc.; http://wso2.com > V.P Apache Web Services; http://ws.apache.org/ > Linkedin; http://www.linkedin.com/in/ssagara > Blog ; http://ssagara.blogspot.com > > -- 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
