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. [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]>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
