Re: [Architecture] [SP-Dashboards] Internationalization of widgets
Hi All,
IMO widget itself needs to contain all the necessary files which are
substantially independent of the host page. Host page needs to have the
capability of getting and load necessary dependencies accordingly.
I'm not fully aware of the path that you mentioned in option 2. But If
everything on same container +1 for that approach.
Regards,
*Dakshika Jayathilaka*
PMC Member & Committer of Apache Stratos
Associate Technical Lead
WSO2, Inc.
lean.enterprise.middleware
0771100911
On Wed, Nov 21, 2018 at 5:05 PM Ruwini Wijesiri wrote:
> Hi,
>
> We have a requirement to internationalize the text content of widgets. So
> far we have identified 2 approaches to achieve this;
>
>1. Have a single locale.json file that contains the message id to text
>mapping for all locales within the *'resource'* directory of the
>widget. However. this will result in the the widget needing to be re-built
>whenever a change is made to the locale.json file.
>
>2. Have the {locale}.json files in carbon-dashboards and load the json
>files to the widget via an API call in the same manner it is done in the SP
>portal. Currently, the SP portal locale files are located in directory
>*'components/dashboards-web-component/public/locales/'*. The widget
>specific locale files could be placed in directory
>
> *'components/dashboards-web-component/public/locales/widgets/{widget_name}/'.
> *
>
> The second approach seems a better alternative as it will eliminates the
> need to re-build widgets when new locales are added.
>
> Any ideas on these 2 approaches or any other approach is highly
> appreciated.
>
> Thanks,
> Regards,
> Ruwini.
> --
> Ruwini Wijesiri
> Software Engineer,
> WSO2 Inc.
>
> Mobile : +94716133480
>
> <http://wso2.com/signature>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [IS] Template Management for User Input Prompt in Adaptive Authentication
Hi Chamath, Is this same as current templates available for adaptive auth script? Or different one? Can you provide the sample with this? Why do system administrators need to know handlebars instead javascript? Regards, *Dakshika Jayathilaka* PMC Member & Committer of Apache Stratos Associate Technical Lead WSO2, Inc. lean.enterprise.middleware 0771100911 On Thu, Aug 23, 2018 at 11:14 AM Chamath Samarawickrama wrote: > > Hi all, > > I’m currently working on a project for adding template management for user > input prompt in adaptive authentication. Adaptive authentication is a > feature that will be released with IS 5.7.0 and with that, the admin users > will be able to configure the authentication flow with the help of scripts. > There, the admin can configure the script to prompt the end-user for > additional input. (eg: some information that is not there in the claims). > Currently, there is no functionality to manage these pages that would be > rendered at the authentication endpoint. > > What this project would provide is a platform for the admin, to manage > templates that would be rendered to the end-user, based on his > configuration of the script. There, I will be implementing a UI to add/edit > templates, an API (Template API), and a database schema to save the > templates. The template API would handle the actions on the management > console side ( adding templates, updating templates, deleting templates, > exporting templates). Furthermore, the admin users should be using > Handlebars.js when creating the templates in the management console. > > The template data will be called via an endpointParam when populating the > AuthenticationContext object. The template data String will then be called > with the other context parameters through the context API and then would be > rendered at the Authentication Endpoint. > > The aforementioned details are depicted in the diagram below. > > Would highly appreciate if you can give any comments or feedback on this. > > Thanks > > > -- > *C**h**amath Samarawickrama* > Intern | WSO2, Inc. > Mobile : +94772598944 > Twitter <https://twitter.com/htamahc> LinkedIn > <https://www.linkedin.com/in/htamahc/> GitHub > <https://github.com/htamahc> > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [IAM] public SPA client app JS approach
Hi Chinthaka, Seems AppAuth-JS closed the PR without merging. https://github.com/openid/AppAuth-JS/pull/67#issuecomment-411537622 Is that possible to implement without forking the base lib? Regards, *Dakshika Jayathilaka* PMC Member & Committer of Apache Stratos Associate Technical Lead WSO2, Inc. lean.enterprise.middleware 0771100911 On Mon, Jul 30, 2018 at 2:29 PM Chinthaka Senanayaka wrote: > Hi all, > > I am writing a wrapper library (JS node module) to hide complexities of > integrating public client apps with OIDC flows (implicit and auth with > PKCE) with WSO2 IS. > > We selected AppAuth-JS library <https://github.com/openid/AppAuth-JS> as > base OIDC library and will wrap this with our library (named as > wso2is-client). And this is the only library we could find which supports > implicit and PKCE flows in a maintainable way. > > Below sequence diagrams depict our approach. > > > > With this, we can give the public client app developer an easy way to > integrate with WSO2 IS OIDC flows. > > Limitations of the AppAuth-Js library: > 1. For now we will use browser redirection based authentication only since > AppAuth-JS library supports only that (no popup and iframe approaches). > 2. At the same time, AppAuth-JS library uses Jquery base Ajax requests. > Thus we have to follow that as well. > > Besides, we will send a PR to Google's AppAuth-JS library > <https://github.com/openid/AppAuth-JS> with some supporting features and > our library code PR will also be available for review. And we welcome for > any improvement points made by you in architecture level as well as coding > level. > > Anyway, if you have any comments for us to improve, please reply. > > Furthermore, there will be some sample apps to show how to integrate > wso2is-client node module library and documentations as well. > > -- > Thanks, > Chinthaka Senanayaka > Technical Lead - Engineering | WSO2 > > Email: chintha...@wso2.com > Mobile: +94 77 11 99 603 > Web: http://wso2.com > > [image: http://wso2.com/signature] <http://wso2.com/signature> > ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [IAM] Function Library for Adaptive Authentication
Hi Anuradha, Can you clarify below questions 1. Is this contain only just functions or js class? 2. How are we allowing users to add this on adaptive steps? 3. What will happen if they use the same method names on there? Is there any package model or how it works? Regards, *Dakshika Jayathilaka* PMC Member & Committer of Apache Stratos Associate Technical Lead WSO2, Inc. lean.enterprise.middleware 0771100911 On Wed, Aug 8, 2018 at 3:51 PM Anuradha Karunarathna wrote: > Hi all, > > > Currently, I am working on a project to manage function libraries in > adaptive authentication. Here is a brief summary of the project and my > progress. > > Introduction: > > WSO2 Identity server has a feature called script based adaptive > authentication. It provides the facility to change the authentication flow > based on conditions in JavaScript. However, at the moment each service > provider needs to have its own set of Javascript functions. Therefore, if > the identity admin needs to have the same function for several service > provider, the same JS function needs to be duplicated. As a result, the > process of managing authentication scripts gets difficult. > > As a solution to this problem, it is going to introduce a set of function > libraries which can be required in authentication scripts. Under this > project, I will implement UI to add/delete/edit/import/export function > libraries, a database schema to hold text artifact libraries, a method to > include the functions from the library to authentication scripts and a > common set of functions as standard libraries. > > Progress: > > Currently, I am designing the required UI to manage function libraries to > WSO2 Identity Server Management Console. The designed UIs are as follows. > > > Function library management option is available under the manage section > of the main menu in IS Management console. > > > UI of adding new function library: > > It prompts for a unique function library name which will be used when > importing it in authentication scripts, a description about the function > library and an editor to write the function library. > > > UI of listing function libraries: > > This page prompts the available list of function libraries with the edit, > delete, export functionalities. > > Please provide any feedback on designs. > > Thanks, > > *Anuradha Karunarathna* > Intern-Software Engineering | WSO2,inc. > > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [APIM][API-Manager gateway] Attaching Labels for APIs
Hi, IMO its better if we share the real user story behind the creating labels in gateway level. (Is it only for grouping purpose? ) Also whats the difference between current tags vs labels? Regards, *Dakshika Jayathilaka* PMC Member & Committer of Apache Stratos Associate Technical Lead WSO2, Inc. lean.enterprise.middleware 0771100911 On Tue, May 8, 2018 at 11:05 AM Chamin Dias <cham...@wso2.com> wrote: > Hi all, > > Thanks for the responses. > > This is to communicate a concern/conclusion regarding the flow (attaching > labels). > > *Using the UI (API Publisher)* > > 1. We have decided to fetch the existing labels and provide the option to > select the labels. This improved the user experience because there is no > need to remember the labels in advance. > > 2. In this case, (since the attached labels are already there in the > system) we do not need to validate the labels at API creation time. > > > *Using the REST API* > > 1. As discussed, we hope to introduce new section in the payload. > Eg : > "labels":[ > "wso2", > "development" > ] > > 2. In this approach, the user needs to know the existing labels in > advance. However, if he types a non existing label (by mistake or > intentionally), we need to validate the labels at API creation (saving) > time. We will attach only the existing/valid labels and create the API > (because adding new labels is an admin task - in admin dashboard). We can > print a message in the console saying that the invalid labels have been > skipped. > > 3. Accordingly (when using the REST API) we need to do the validation > call, at API creation time. > > Please provide your feedback if you have any optimization for this. > > Thanks. > > On Mon, May 7, 2018 at 10:33 AM, Sanjeewa Malalgoda <sanje...@wso2.com> > wrote: > >> +1. Lets go with rxt option for the moment as other search options are >> also based on same design. >> >> Thanks, >> sanjeewa. >> >> On Sun, May 6, 2018 at 12:48 AM, Prasanna Dangalla <prasa...@wso2.com> >> wrote: >> >>> Hi, >>> >>> On Fri, May 4, 2018 at 5:58 PM Nuwan Dias <nuw...@wso2.com> wrote: >>> >>>> I think it should be in the rxt as a field. Storing it as a property >>>> seems like a hack to me. And yes, storing on a separate DB will cause >>>> complications with queries since the rest of the data is in the rxt. >>>> >>> >>> If we Include as a feild in API rxt, then the search issue that Malintha >>> pointed out will also be solved. >>> +1 to go with a feild in the rxt. >>> >>> Thanks >>> Prasanna >>> >>>> >>>> On Fri, May 4, 2018 at 5:45 PM, Malintha Amarasinghe < >>>> malint...@wso2.com> wrote: >>>> >>>>> Hi, >>>>> >>>>> On Fri, May 4, 2018 at 11:15 AM, Prasanna Dangalla <prasa...@wso2.com> >>>>> wrote: >>>>> >>>>>> >>>>>> HI, >>>>>> >>>>>> >>>>>> >>>>>> On Fri, May 4, 2018 at 11:07 AM Chamin Dias <cham...@wso2.com> wrote: >>>>>> >>>>>>> On Fri, May 4, 2018 at 9:19 AM, Dinusha Dissanayake < >>>>>>> dinus...@wso2.com> wrote: >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> AFAIU we are going to use labels when downloading a subset of APIs >>>>>>>>> via Microgateway. If it is not mandatory to have the labels, how are >>>>>>>>> we >>>>>>>>> going to handle the APIs without labels in Microgateway? Are we not >>>>>>>>> going >>>>>>>>> to download the APIs without labels? >>>>>>>>> >>>>>>>>> As Sachini has mentioned above if a subset of APIs to be deployed >>>>>>>> in the micro gateway, it needs to have a label. Say if APIs have a >>>>>>>> default >>>>>>>> label called "def_label". Then if we call "setup def_label", all the >>>>>>>> APIs >>>>>>>> will be deployed in the micro gateway. Hence I do not think having a >>>>>>>> default label would add a significant value. Only the APIs needed to be >>>>>>>> deployed in the micro gateways will have labels AFAIR. (please correct
Re: [Architecture] [IS] REST endpoint for Claim Management in IS
Hi Chiran,
Aren't we support for adding local claim via REST API?
Also, don't we need to add "409 conflicts" for the scenarios that resource
already exists?
Regards,
*Dakshika Jayathilaka*
PMC Member & Committer of Apache Stratos
Associate Technical Lead
WSO2, Inc.
lean.enterprise.middleware
0771100911
On Sat, Feb 10, 2018 at 9:34 AM, Chiran Wijesekara <chir...@wso2.com> wrote:
> Hi Isura,
>
> Thank you very much for your feedback.
> I had gone through your comments and did the changes accordingly. Please
> find the updated Swagger .yaml [1] attached below.
> [1] https://app.swaggerhub.com/apis/chirankavinda123/claim_
> management_service_endpoint/1.0.0
>
> Thank You.
>
> On Sat, Feb 10, 2018 at 1:19 AM, Isura Karunaratne <is...@wso2.com> wrote:
>
>> Hi Chiran,
>>
>> Please find the inline comments.
>>
>> 1)
>>
>>
>> POST/dialects/{id}
>> <https://app.swaggerhub.com/apis/chirankavinda123/claim_management_service_endpoint/1.0.0#/operations/default/addClaimDialect>
>> Add New Claim Dialect.
>> The context for the posting a dialect should be like bellow.
>>
>>
>> POST/dialects
>> <https://app.swaggerhub.com/apis/chirankavinda123/claim_management_service_endpoint/1.0.0#/operations/default/addClaimDialect>
>> Add New Claim Dialect.
>> Also, the request body should contain, dialect URI (name) with the
>> external claims array.
>>
>>
>> 2)
>>
>>
>>
>> DELETE/dialect/{id}
>> <https://app.swaggerhub.com/apis/chirankavinda123/claim_management_service_endpoint/1.0.0#/operations/default/removeClaimDialect>
>> Delete Claim Dialect
>> Delete claim dialect should be like bellow
>>
>> DELETE/dialects/{id}
>> <https://app.swaggerhub.com/apis/chirankavinda123/claim_management_service_endpoint/1.0.0#/operations/default/removeClaimDialect>
>> Delete Claim Dialect
>>
>>
>> 3)
>>
>>
>> GET/dialect
>> <https://app.swaggerhub.com/apis/chirankavinda123/claim_management_service_endpoint/1.0.0#/operations/default/getClaimDialects>
>> Get Available Claim Dialects
>>
>> Get Available Claim Dialects should be as follows.
>>
>>
>> GET/dialects
>> <https://app.swaggerhub.com/apis/chirankavinda123/claim_management_service_endpoint/1.0.0#/operations/default/getClaimDialects>
>> Get Available Claim Dialects
>>
>>
>> 4)
>>
>>
>> PUT/dialect
>> <https://app.swaggerhub.com/apis/chirankavinda123/claim_management_service_endpoint/1.0.0#/operations/default/renameClaimDialect>
>> Update existing claim dialect.
>>
>> Update existing claim dialect should be as follows,
>>
>> PUT/dialects/{id}
>> <https://app.swaggerhub.com/apis/chirankavinda123/claim_management_service_endpoint/1.0.0#/operations/default/renameClaimDialect>
>> Update existing claim dialect.
>>
>>
>>
>> 5)
>>
>>
>> PUT/dialects/{id}/claims
>> <https://app.swaggerhub.com/apis/chirankavinda123/claim_management_service_endpoint/1.0.0#/operations/default/updateExternalClaim>
>> update an external claim.
>> DELETE/dialects/{id}/claims
>> <https://app.swaggerhub.com/apis/chirankavinda123/claim_management_service_endpoint/1.0.0#/operations/default/removeExternalClaim>
>> Delete external Claim
>>
>> Update and delete External claims should be as follows
>>
>>
>> PUT/dialects/{dialect-id}/claims/{claim-id}
>> <https://app.swaggerhub.com/apis/chirankavinda123/claim_management_service_endpoint/1.0.0#/operations/default/updateExternalClaim>
>> update an external claim.
>> DELETE/dialects/{dialect-id}/claims/{claim-id}
>> <https://app.swaggerhub.com/apis/chirankavinda123/claim_management_service_endpoint/1.0.0#/operations/default/removeExternalClaim>
>> Delete external Claim
>>
>>
>>
>>
>>
>>
>>
>> PUT/attributes
>> <https://app.swaggerhub.com/apis/chirankavinda123/claim_management_service_endpoint/1.0.0#/operations/default/updateLocalClaim>
>> Update a Local Claim.
>>
>> Update a Local Claim should be as follows
>>
>>
>> PUT/attributes/{local-claim-id}
>> <https://app.swaggerhub.com/apis/chirankavinda123/claim_management_service_endpoint/1.0.0#/operations/default/updateLocalClaim>
>> Update a Local Claim.
>>
>>
>> Thanks
>> Isura.
>>
>>
>>
>> On Fri, Feb 9, 2018 at 5:30 PM, Chiran Wijesekara <chir...@wso2.com>
>> wrote:
>>
>>> Hi all,
>>>
>>> Please find the
Re: [Architecture] CLI Client for the Message Broker
Hi All, IMO we need to support basic level features such as *--help*, *--version* and *--verbose* on each CLI tool that we are building. Also, we need to think about the standard output for each scenario as well. Shall we add few samples for that as well? Regards, *Dakshika Jayathilaka* PMC Member & Committer of Apache Stratos Associate Technical Lead WSO2, Inc. lean.enterprise.middleware 0771100911 On Wed, Feb 7, 2018 at 10:24 AM, Eranda Rajapakshe <eran...@wso2.com> wrote: > Hi Imesh, > > Yes, we are going to include help command into the client. Thanks for the > reference, it looks interesting. > > Thanks, > > On Wed, Feb 7, 2018 at 10:13 AM, Imesh Chandrasiri <ime...@wso2.com> > wrote: > >> Hi Eranda, >> >> A small clarification on the commands. Could these have a '--help' >> command where the syntax and the usage of the command is printed? IMHO it >> would benefit the user to figure out the command usage then and there >> without having to read the documentation. This is a nice article[1 >> <https://zapier.com/engineering/how-to-cli/>] on some UX views of a CLI. >> >> [1] - https://zapier.com/engineering/how-to-cli/ >> >> ___ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > *Eranda Rajapakshe* > Software Engineer > WSO2 Inc. > Mobile : +94784822608 > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [Dashboard] Introducing a base widget component
Hi All,
AFAIK shadow DOM not supported by many browsers ATM. Can't we simply use
unique ID and extend the class with ID to prevent the CSS conflicts.
Regards,
*Dakshika Jayathilaka*
PMC Member & Committer of Apache Stratos
Associate Technical Lead
WSO2, Inc.
lean.enterprise.middleware
0771100911
On Thu, Aug 31, 2017 at 1:44 PM, Lasantha Samarakoon <lasant...@wso2.com>
wrote:
> Hi all,
>
> In the new React based dashboard widget is defined as a another React
> component. ATM these widgets are basic React components which extends from
> React.Component class.
>
> But within these widgets we need to provide some extra capabilities for
> widget developers such as providing mechanism to inter-communicate among
> widgets via pub/sub, provide APIs to save widget states, etc. And also
> there is another issue with the current implementation i.e. the CSS styles
> embedded within a widget may conflict with styles applied to dashboard and
> other widgets (no CSS isolation).
>
> *Solution:*
>
> As a common solution for these requirements we thought of introducing a
> base widget class so that all the other widgets can extend from this base
> class instead of React.Component. By introducing this base class we can
> provide additional capabilities to widget developers.
>
> Ex. 1) Pub/sub
>
> For the Pub/sub implementation base widget component can expose methods
> and events for widgets to use (methods for publishing/subscribing to topic).
>
> Ex. 2) CSS isolation
>
> For CSS isolation we can isolate the widget content using React shadow
> DOM. For that we can introduce a new method called renderWidget() in the
> widget base class and all the widgets can define the renderWidget() instead
> of the React's render() method. Within the render() method of the widget
> class we can invoke the renderWidget() method and wrap the resultant
> content using React shadow DOM. High level implementation of those
> components will be as follows.
>
> *Widget base component:*
>
> class Widget extends React.Component {
> /* ... */
> render() {
> return (
>
> renderWidget()
>
> );
> }
> /* ... */
> }
>
>
> *Widget component:*
>
> class MyWidget extends Widget {
> /* ... */
> renderWidget() {
> return ;
> }
> /* ... */
> }
>
>
> Any feedback on this?
>
> Regards,
>
> *Lasantha Samarakoon* | Software Engineer
> WSO2, Inc.
> #20, Palm Grove, Colombo 03, Sri Lanka
> Mobile: +94 (71) 214 1576 <+94%2071%20214%201576>
> Email: lasant...@wso2.com
> Web:www.wso2.com
>
> lean . enterprise . middleware
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] How valid is sending TOTP code to email? How about sending it over SMS?
+1 for support both options. Then, admin can configure either SMS or E-mail or both depending on their service availability. Regards, *Dakshika Jayathilaka* PMC Member & Committer of Apache Stratos Associate Technical Lead WSO2, Inc. lean.enterprise.middleware 0771100911 On Mon, Jul 24, 2017 at 4:40 PM, Harsha Thirimanna <hars...@wso2.com> wrote: > > > On 18 Jul 2017 10:14 am, "Johann Nallathamby" <joh...@wso2.com> wrote: > > Hi All, > > Usually we send long lived codes to email and short lived codes to SMS. > Because opening email client and checking the code may take time, depending > on whether user has to log in to his email account, use 2FA for his email, > etc. The TOTP code is short lived (90s). I think it's better to send this > code over SMS or have both functionalities. What do you think? > > > Don't we need to have a choice to user to either email/sms or both ? > > Are there any chance to select one of phone number claim by multiple ? > > > Thanks & Regards, > Johann. > > -- > > *Johann Dilantha Nallathamby* > Senior Lead Solutions Engineer > WSO2, Inc. > lean.enterprise.middleware > > Mobile - *+9476950* > Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>* > > > ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [UUF] Removing creation of inline JS script tags upon calling sendToClient()
Hi All,
IMHO if we are going forward with meta tag we need to think about HTML
validation as well. AFAIK according to the specification, we can't use
value or data attrib with meta tags[1]. +1 for using content attrib.
[1] https://www.w3.org/TR/html5/document-metadata.html#the-meta-element
*Dakshika Jayathilaka*
PMC Member & Committer of Apache Stratos
Associate Technical Lead
WSO2, Inc.
lean.enterprise.middleware
0771100911
On Wed, May 31, 2017 at 4:05 PM, Jerad Rutnam <je...@wso2.com> wrote:
> Hi Sajith,
>
> As for the offline discussion we had. IMO I feel it's ok to use tag
> for it. But have some minor suggestions, please see the example below.
>
>
>
> Cheers,
>
> On Wed, May 31, 2017 at 1:04 PM, SajithAR Ariyarathna <sajit...@wso2.com>
> wrote:
>
>> Hi All,
>>
>> We are in the process of doing $subject.
>>
>> # What is sendToClient() function?
>>
>> Its a server-side JS function provided by UUF that can be used to send a
>> server-side value to the client-side.
>>
>>
>> function onGet(env) {
>>
>> sendToClient("contextPath", env.contextPath);
>>
>> }
>>
>>
>> Which will produce following inline-script
>>
>> var contextPath="/portal";
>>
>>
>> However, we are hoping to set the Content-Security-Policy header to
>> disable inline-JS scripts as a security measure against XSS
>> vulnerabilities (as suggested by the security team).
>>
>> Content-Security-Policy: upgrade-insecure-requests, *default-src 'self'*,
>> frame-ancestors
>> 'none'
>>
>> So setting the Content-Security-Policy header to above will break the
>> sendToClient functionality.
>>
>> # Proposing solution
>>
>> Create a tag in the page header that contains all the values sent
>> from server-side.
>>
>>
>>
>>
>>- Only one tag will be created.
>>- All the values sent from server-side will be composed into a JSON,
>>and that JSON string will be encoded to Base64.
>>- In order to access a value, webapp developer has to use the
>>UUFClient.
>> - e.g. UUFClient.fromServer("contextPath") which will return
>> "/portal"
>>- Please note that, this will be a breaking change for existing UUF
>>apps/component that utilizes sendToClient() function.
>>
>> WDYT?
>>
>> Thanks.
>> --
>> Sajith Janaprasad Ariyarathna
>> Senior Software Engineer; WSO2, Inc.; http://wso2.com/
>> <https://wso2.com/signature>
>>
>
>
>
> --
> *Jerad Rutnam*
> *Senior Software Engineer*
>
> WSO2 Inc.
> lean | enterprise | middleware
> M : +94 77 959 1609 | E : je...@wso2.com | W : www.wso2.com
>
> <https://wso2.com/signature>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [IoT] App Management of IoT Server
Hi Chathura, Do we have a plan for managing app versioning, grouping in app publisher and store? Regards, *Dakshika Jayathilaka* PMC Member & Committer of Apache Stratos Associate Technical Lead WSO2, Inc. lean.enterprise.middleware 0771100911 On Tue, Apr 18, 2017 at 4:51 PM, Chathura Dilan <chathu...@wso2.com> wrote: > Hi All, > > We have planned to rewrite App Management component for IoT server to make > it more scalable and efficient. As the initial step we are focusing on the > app store and publisher. > > The business user stories of the app management as follows. > > App developer > App developer creates apps for users. He can use app publisher console to > distribute his application to users. He also is capable of distributing > correct app to relevant user. > > App Publisher > App publisher is responsible of verify the application before it is > publish it in the store > > App User > Can browse the app store, subscribe to an application to > download/get/install an app > > > This will be the high level arcihtecture diagram. > > > 1. App management core consist of web app publisher, store webapps. > 2. It also expose its services as REST for third parties and for the > publisher and store. > 3. App types are plugable to the app management core. > 4.Plugins consist of UI elements which is related to publisher and store. > Those UI elements will be rendered in the page based on the app type. > 5. App types can have common attributes such as id, name and some app type > related attributes. These attributes can be defined in a descriptor in the > plugin to generate its own database table with fields to store information > about the apps. > > This is the initial plan on how we are going to design the app management > component. I will update this thread with more information. > > -- > Regards, > > Chatura Dilan Perera > *Associate Tech Lead** - WSO2 Inc.* > www.dilan.me > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [C5] [IS 6.0.0] Delete Users UI for IS 6.0.0 Admin Portal
Hi All, As Minoli pointed out, we are not showing secondary actions as we can't do anything without multiple selections. This is a normal pattern that we are using in UX and its called "*progressive disclosure"*. [1] IMHO we can improve this view further more. We have created an issue to track that. [2] [1] https://www.nngroup.com/articles/progressive-disclosure/ [2] https://github.com/wso2-dev-ux/theme-wso2/issues/42 Regards, *Dakshika Jayathilaka* PMC Member & Committer of Apache Stratos Associate Technical Lead WSO2, Inc. lean.enterprise.middleware 0771100911 On Mon, Apr 3, 2017 at 3:16 PM, Minoli Perera <mino...@wso2.com> wrote: > Hi Sasikala, > > >> So my understanding is that the normal view hides options to delete all, >> lock, etc., and once we hit the select button the delete view gets opened. >> Is there a particular reason for us to not show all options by default? >> > > The main purpose of the view[1] is listing users with inline actions. > Actions such as delete/lock/disable/activate on the top of the table are > secondary actions and are used only when the bulk select is activated (When > the rows are selectable) Showing them in default (un-selectable) state > would confuse the user as those actions would not relate to any > functionality at that point. > > [1] https://github.com/wso2-dev-ux/product-is/blob/master/ > Wireframes/admin-portal/v5/3.22_User_Listing-when_select_is_clicked.png > > Thanks, > -- > Minoli Perera, > Software Engineer, WSO2, Inc. > E-mail : mino...@wso2.com > Mobile : +94771567527 <+94%2077%20156%207527> > <http://wso2.com/signature> > ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] Fwd: [APPM] Support custom theme for tenants in store
Hi All, IMO we need to provide sample theme archive with possible overrides including exact file names that they can include. Regards, *Dakshika Jayathilaka* PMC Member & Committer of Apache Stratos Associate Technical Lead WSO2, Inc. lean.enterprise.middleware 0771100911 On Wed, Aug 24, 2016 at 9:13 AM, Jenananthan Yogendran <jenanant...@wso2.com > wrote: > Hi All, > > In App Manager we need to support custom themes for tenants. We hope to > provide the tenant custom theme support like APIM[1]. > > Currently APPM has three asset types (webapp,site,mobileapp) as extension > types.Each asset type has its own theme by overriding the some theme > resources of the default theme.Where default > theme provides common theme resources for all asset types. > > *Current structure* > > store > |--extensions > | |--assets > | |--webapp > | *|--themes* > | *|--store* > | |--mobileapp > | *|--themes * > | *|--store* > |--*themes* > * |--store* > > Where "themes/store" is default theme directory and each asset has > overridden this theme under extensions directory. > > So when we provide the custom theme support for tenants we need to focus > on providing ability to customize the default theme resources as well as > theme resources overridden in asset level. > E.g Theme resources for header and footer is common to all asset types and > which comes from the default theme.Theme resources for asset overview page > is different for each assets and they come from > asset level. > > > As I had offline discussion with Sameera M , we came up following > directory structure for adding custom theme. > > *Custom theme support* > > store > |--extensions > | |--assets > | |--webapp > | | |--themes > | | |--store > | | > | |--mobileapp > | |--themes > | |--store > |--themes >|--store >| >*|-- * > *|--extensions* > *| |--* > *| |--themes * > *| |--store* > *|* > *|* > *|--themes* > *|--store* > > >- Resources in themes/store directory can be overridden by tenants in >/themes/store. >- Reduces in store/extensions/assets//themes/store can be >overridden by tenants in store//extension >s/assets//themes/store > > > e.g > > store > |--extensions > | |--assets > | |--webapp > | | |--themes > | | |--store > | | |--css > | | |--overview-style.css > | |--mobileapp > | |--themes > | |--store > |--themes >|--store >| |--css >||--header-style.css >| >|--*eng.com <http://eng.com>* > |--extensions > | |--webapp > | |--themes > | |--store > | |--css > | |--overview-style.css > | > | > |--themes > |--store > --css > --header-style.css > > > > *Implementation* > > 1. Tenant user will be provided an interface(in admin-dashboard) to upload > the custom theme > 2. Theme resources should be uploaded in zip format. > 3. Provide configuration option to whitelist the resource files that can > be uploaded > 4. Uploaded resource files will be stored in store under the directory > having tenant name > > store > | > |--themes >| >|--<*tenantdomain> * > *|--extensions* > *| |--* > *| |--themes * > *| |--store* > *|* > *|* > *|--themes* > > > *|--store* > 5. if deployment has multiple store nodes, custom theme should be > uploaded in one store node >and should be synced using suitable sync mechanism like rsync. > > > Appreciate your feedback. > > [1] http://wso2-oxygen-tank.10903.n7.nabble.com/APIM-ES-Store-Su > pporting-custom-themes-for-tenants-td92555.html > > > Thanks > -- > Jenananthan Yogendran > *Senior Software Engineer,* > *WSO2 inc., http://wso2.com <http://wso2.com>* > > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [Dev] Creating a Dashboard for Web Application Statistics Monitoring for Application Server 6.0.0
Hi Kalpa, I have noticed a minor issue on top-level blocks. IMO we need to increase the font size of each block title a little bit to give proper prominence. Regards, *Dakshika Jayathilaka* PMC Member & Committer of Apache Stratos Associate Technical Lead WSO2, Inc. lean.enterprise.middleware 0771100911 On Wed, Aug 3, 2016 at 2:35 PM, Kalpa Welivitigoda <kal...@wso2.com> wrote: > Hi all, > > I am continuing the work of HTTP statistics dashboard and it will serve > the analytics aspect of AS 6.0.0 (analytics-http). Since it is HTTP > statistics monitoring, this can be used in other products as well for the > said purpose. In AS, we are using a tomcat valve to capture and publish > following data. I think it's better we figure out any other data that is > needed for other products since this has the potential to be used platform > wide. > > List of data that is published with the statistics publishing valve in AS > 6.0.0, > > >- Application name >- Application version >- Application display name >- Session ID >- Request URI >- Request headers >- User Agent header >- Response time >- Response content type >- HTTP Status code of the response > > > In analytics-http product, we are presenting the following information, > > >- Total number of requests and min, max and avg per minute >- Response time min, max and avg per minute >- Number of sessions and avg per minute >- Number of error count and the percentage error over total number of >requests >- The list of applications with, > - average request count for the last minute, last hour and last day > - total number of requests > - percentage of error count >- Average request count, response time and error count variation over >time >- Visualization and tabular format of the following information with >the number of requests, >- Browser > - Operating system > - Device type > - HTTP status codes of the response > - Language > - Country >- Tabular format of the following information with the number of >requests, > - Sub context > - Referrer > > I have attached a screen capture of the latest overview page, the rest is > WIP. > > Highly appreciate your thoughts. > > > > On Sat, Jan 30, 2016 at 11:13 AM, Manoj Kumara <ma...@wso2.com> wrote: > >> Hi Manjula, >> >> At the moment Lochana is integrating the work we done for AS 5.3.0 and >> this feature is not yet included on AS 6.0.0 which is pure Tomcat bases. >> You can find the branch on [1]. >> >> Lochana will update once the initial work is included. >> >> [1] https://github.com/wso2/product-as/tree/wso2as-6.0.0 >> >> *Manoj Kumara* >> WSO2 Inc. *| **lean. enterprise. middleware.* >> *Mobile:* +94 713 448188 >> >> On Fri, Jan 29, 2016 at 10:34 AM, Manjula Rathnayake <manju...@wso2.com> >> wrote: >> >>> Hi all, >>> >>> +1 for getting this in App Cloud. >>> >>> Can anyone point me a download link for latest AS-6.0.0? >>> >>> thank you. >>> >>> On Fri, Jan 29, 2016 at 9:15 AM, Sagara Gunathunga <sag...@wso2.com> >>> wrote: >>> >>>> >>>> >>>> On Fri, Jan 29, 2016 at 8:53 AM, Dimuthu Leelarathne <dimut...@wso2.com >>>> > wrote: >>>> >>>>> Hi Lochana, >>>>> >>>>> Can this dashboard be reused by the MSS? >>>>> >>>> >>>> Yes, that was the plan we discussed, in fact current AS dashboard is >>>> already being used with MS with few tweaks. This dashboard is basically >>>> not product specific it can be used anywhere for HTTP monitoring only >>>> change is the way we capture HTTP traffic, in AS as a Tomcat Valve in MS as >>>> an Interceptor etc. >>>> >>>> >>>>> @Manjula - App Cloud should be using this dashboard. >>>>> >>>> >>>> +1 Great way to put this into action. >>>> >>>> Thanks ! >>>> >>>>> >>>> >>>>> >>>>> thanks, >>>>> Dimuthu >>>>> >>>>> On Mon, Jan 25, 2016 at 12:50 PM, Lochana Ranaweera <locha...@wso2.com >>>>> > wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> We had a design review meeting on this and I'm stating a summary of >>>>>> wh
Re: [Architecture] Modification of the gadget generation wizard's extension structure
Hi All, Ideally, we need to provide an option to re-edit once they generated. AFAIK we don't have that option yet. Regards, *Dakshika Jayathilaka* PMC Member & Committer of Apache Stratos Associate Technical Lead WSO2, Inc. lean.enterprise.middleware 0771100911 On Tue, Jun 7, 2016 at 11:34 PM, Manuranga Perera <m...@wso2.com> wrote: > How would a user modify or regenerate with slight change? > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Modification of the gadget generation wizard's extension structure
Hi All,
IMO it's better if we can maintain third-party libraries as a separate
entity. Usually, most of the third party libs have their own dependencies
(ex: some CSS files refer images/ fonts ). If we place them separately it's
hard to identify relevant dependency at a glance.
At the same time, I would like to propose to have library version as well.
This will really useful if someone wants to upgrade third-party lib etc.
Regards,
*Dakshika Jayathilaka*
PMC Member & Committer of Apache Stratos
Senior Software Engineer
WSO2, Inc.
lean.enterprise.middleware
0771100911
On Tue, Jun 7, 2016 at 3:11 PM, Tanya Madurapperuma <ta...@wso2.com> wrote:
> Hi all,
>
> During an offline discussion with Jerad following modification were
> suggested regarding the directory structure of the extension model. All
> these changes are subjected to js and css file locations.
>
> *Chart template structure*
>
> |── line-chart
> │ ├── css
> │ │ └── line-chart.css
> │ └── js
> │ ├── d3.min.js
> │ ├── vega.js
> │ └── VizGrammar.min.js
>|── config.json
> ├── api.js
>
>
> *Changes to the existing model*
>
>- rename index.js to api.js
>- rename chart-libs folder to js
>- have a css folder in the same level
>
>
> *Generated gadget structure*
>
> └── test_gadget
> │ │ ├── conf.json
> │ │ ├── css
> │ │ │ └── line-chart.css
> │ │ ├── gadget-controller.jag
> │ │ ├── gadget.json
> │ │ ├── index.png
> │ │ ├── index.xml
> │ │ └── js
> │ │ ├── core
> │ │ │ ├── gadget-core.js
> │ │ │ ├── line-chart-api.js
> │ │ │ └── provider-api.js
> │ │ ├── d3.min.js
> │ │ ├── vega.js
> │ │ └── VizGrammar.min.js
>
>
> *Changes to the existing model*
>
>- Instead of the *chart-libs* folder inside *js* folder, have a *core
> *folder
>inside *js *folder and place chart specific js files in js folder
>
>
> *Folder structure for storing common libs*
>
> portal
> |── gadget-commons
>
>├── css
>│ └── common.css
>└── js
>└── common.js
>
>
> *Changes to the existing model*
>
>- Now we have common libs inside portal/libs/common-chart-libs/
>
> *chart config.json*
>
> "common": {
> "js": ["common"],
> "css": ["common"]
> },
> "chart": {
> "js": ["d3.min", "vega", "VizGrammar.min"],
> "css": ["line-chart"]
> }
>
> *existing config.json*
>
> "common-libs" : ["wso2gadgets","chart-utils"],
> "chart-libs" : ["d3.min","vega","VizGrammar.min"]
>
> I think this model is cleaner and intuitive than the exiting model.
> AFAIK existing wizard is only used for IOT analytics. If there are no
> concerns from them shall we move to this new model?
>
> @ Suho, Dunith : WDYT ? Will this incur lot of changes from IOT side?
> Appreciate your input.
>
> Thanks,
> Tanya
>
> --
> Tanya Madurapperuma
>
> Senior Software Engineer,
> WSO2 Inc. : wso2.com
> Mobile : +94718184439
> Blog : http://tanyamadurapperuma.blogspot.com
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [PC] Web based flowchart editor using jsPlumb
Hi, Can you share the notes that taken during the review. Regards, *Dakshika Jayathilaka* PMC Member & Committer of Apache Stratos Senior Software Engineer WSO2, Inc. lean.enterprise.middleware 0771100911 On Fri, Mar 18, 2016 at 12:13 PM, Dilini Mihindra <dili...@wso2.com> wrote: > Hi all, > > I implemented a flowchart editor for the Process Center (PC). It was > implemented using the jsPlumb.js library. A user can describe a BPMN > process by creating a corresponding flowchart diagram using this editor. > There are four basic elements in the editor; the start element, the > decision element, the step element and the end element. > > Following functionalities are included in the editor: > >- User can draw flowchart diagrams using the elements provided in the >palette. >- User can connect elements by drawing connections from source >endpoints to target endpoints. >- These connections can be labeled. >- Elements and connections can be deleted. >- All the elements within the drawing area can be dragged and >re-positioned. >- The step and the decision elements can be re-sized. >- User can edit the label of an element and specify his/her own >descriptions. >- User can modify previously saved flowcharts. > > Please find a document containing more details regarding the flowchart > editor, attached herewith. > > Thank you. > > Dilini Mihindra Mampitiya Arachchi > Intern - Software Engineer > Mobile: +94 710 420 550 > Email: dili...@wso2.com > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Defining UX Pasona for the Platform
Hi Srinath, We are planning to capture existing personas on each wso2 products, IMHO then we will be able to refine them easily. we'll start separate thread for that. Cheers, *Dakshika Jayathilaka* PMC Member & Committer of Apache Stratos Senior Software Engineer WSO2, Inc. lean.enterprise.middleware 0771100911 On Fri, Mar 25, 2016 at 9:05 AM, Srinath Perera <srin...@wso2.com> wrote: > Ping, any updates? > > On Fri, Feb 26, 2016 at 5:42 AM, Dakshika Jayathilaka <daksh...@wso2.com> > wrote: > >> Sure, >> >> We'll try to come up with main personas that we can use. IMHO there may >> be key personas + sub levels. I'll schedule a meeting once we complete >> first draft. >> >> Thank you, >> >> Regards, >> >> *Dakshika Jayathilaka* >> PMC Member & Committer of Apache Stratos >> Senior Software Engineer >> WSO2, Inc. >> lean.enterprise.middleware >> 0771100911 >> >> On Thu, Feb 25, 2016 at 8:54 PM, Srinath Perera <srin...@wso2.com> wrote: >> >>> Hi Dakshika, >>> >>> As per our chat, most of the time, we will use a common set of Pasona's >>> for UX user stories (e.g. developer, DevOps Person, Business User etc). IMO >>> defining them before will save lot of time. Then for most use cases, we can >>> pick one from the list. >>> >>> Could UX team define Pasona's? When we have the first cut, lets do a >>> review. >>> >>> --Srinath >>> >>> -- >>> >>> Blog: http://srinathsview.blogspot.com twitter:@srinath_perera >>> Site: http://people.apache.org/~hemapani/ >>> Photos: http://www.flickr.com/photos/hemapani/ >>> Phone: 0772360902 >>> >> >> > > > -- > > Blog: http://srinathsview.blogspot.com twitter:@srinath_perera > Site: http://home.apache.org/~hemapani/ > Photos: http://www.flickr.com/photos/hemapani/ > Phone: 0772360902 > ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] Fwd: Defining UX Pasona for the Platform
Sure, We'll try to come up with main personas that we can use. IMHO there may be key personas + sub levels. I'll schedule a meeting once we complete first draft. Thank you, Regards, *Dakshika Jayathilaka* PMC Member & Committer of Apache Stratos Senior Software Engineer WSO2, Inc. lean.enterprise.middleware 0771100911 On Thu, Feb 25, 2016 at 8:54 PM, Srinath Perera <srin...@wso2.com> wrote: > Hi Dakshika, > > As per our chat, most of the time, we will use a common set of Pasona's > for UX user stories (e.g. developer, DevOps Person, Business User etc). IMO > defining them before will save lot of time. Then for most use cases, we can > pick one from the list. > > Could UX team define Pasona's? When we have the first cut, lets do a > review. > > --Srinath > > -- > > Blog: http://srinathsview.blogspot.com twitter:@srinath_perera > Site: http://people.apache.org/~hemapani/ > Photos: http://www.flickr.com/photos/hemapani/ > Phone: 0772360902 > ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] We should not create User Management Experiences in Other places
Hi Srinath, I agreed on your point. Currently we don't have shareable way of handling user management on frontend applications. IMHO user management UI needs to separate from application itself and eventually it has to move into a shareable UI component. AFAIK above mentioned wireframes created according to the LA user stories and If we don't think it is a requirement of LA app, we can remove those stories from the workflow. Thank you. Regards, *Dakshika Jayathilaka* PMC Member & Committer of Apache Stratos Senior Software Engineer WSO2, Inc. lean.enterprise.middleware 0771100911 On Mon, Feb 8, 2016 at 1:40 PM, Srinath Perera <srin...@wso2.com> wrote: > Hi Dakshika, > > I was at Log Analyzer UX review today, and UX templates have recreated a > user management UI experience. > > IMHO, this is WRONG. We created Carbon to avoid having to reduce things > like users, registry, Authentication, Authorization, logs etc again for > each product. Things like user management must come from Carbon kernel or > Carbon core. > > It is different discussion whether we need a UI for user management ( this > is discussion about removing Admin UIs). If we need such UI, it should come > from Carbn core. > > Please comment. > > Thanks > Srinath > > -- > > Blog: http://srinathsview.blogspot.com twitter:@srinath_perera > Site: http://people.apache.org/~hemapani/ > Photos: http://www.flickr.com/photos/hemapani/ > Phone: 0772360902 > ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [Dev] Creating a Dashboard for Web Application Statistics Monitoring for Application Server 6.0.0
Hi All, IMO We need to provide similar navigation pattern on DS as wel. This hierarchical navigation model choose due to usability perspective. IMHO Its not good to compromise usability due to technical limitation. AFAIK we can create custom layout as a workaround. Thank you, Regards, *Dakshika Jayathilaka* PMC Member & Committer of Apache Stratos Senior Software Engineer WSO2, Inc. lean.enterprise.middleware 0771100911 On Wed, Jan 13, 2016 at 1:33 PM, Manuranga Perera <m...@wso2.com> wrote: > What ever gadgets we have in old Dashboard can me used in the new DS > server. But the in old app we did some costume navigation model, there is > only limited support for that in current DS. What DS currently support is > fixed one level navigation. > > DAS generated gadgets can be used in DS, so DAS vs DS is a non-issue, it's > the same thing. The real question is if we want to continue the same kind > of hierarchical navigation (each node/app gets a new page in the dashboard) > we had in old AS dashboard. If so we need to continue using the old custom > app OR improve DS to support that. Improvement is not that big but but it > will be a new feature. > > You are very welcome to do so if possible and we are glad to help. > > On Wed, Jan 13, 2016 at 12:50 PM, Sagara Gunathunga <sag...@wso2.com> > wrote: > >> [Moving to architecture@ ] >> >> On Wed, Jan 13, 2016 at 12:30 PM, Lochana Ranaweera <locha...@wso2.com> >> wrote: >> >>> Hi all, >>> >>> I'm currently working on a project on adding web application statistics >>> monitoring feature to the upcoming Application Server 6.0.0. The data >>> collected from the web applications will be published to the Data Analytics >>> Server through a custom Tomcat valve, the development of which has been >>> carried out separately. >>> >>> Once the data has been published, web application statistics should be >>> displayed to the users via a Dashboard. For this, what will be the best >>> suited option out of the following? >>> >>> [1] Utilizing the gadget generation wizard of the DAS >>> >>> [2] Utilizing the Dashboard Server >>> >>> >> When we design the AS dashboard during last year we decided to support 2 >> options, by default dashboard is embedded with the product (AS) and if >> required it's possible to have a dedicated dashboard node as well. >> Personally I'm not up to date about our current policy about product >> dashboards with DAS/DS, whether DS are embedded within the product or can >> we host on DAS or can we have a dedicated DS node etc. May be DAS/DS folks >> can add more insights here ? >> >> Further given the fact that AS6 is not a Carbon based product anymore >> this is a special case as well. I think we need a broad discussion on >> this, better to incorporate this topic with Manoj's design review on >> Monday, also let's get DAS/DS/UX folks too. >> >> Thanks ! >> >> >>> >>> Any suggestions and feedback are highly appreciated. >>> >>> Thanks. >>> >>> -- >>> Lochana Ranaweera >>> Intern Software Engineer >>> WSO2 Inc: http://wso2.com >>> Blog: https://lochanaranaweera.wordpress.com/ >>> Mobile: +94716487055 <http://tel%2B716487055> >>> >>> >>> ___ >>> Dev mailing list >>> d...@wso2.org >>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>> >>> >> >> >> -- >> 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 >> >> >> ___ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > With regards, > *Manu*ranga Perera. > > phone : 071 7 70 20 50 > mail : m...@wso2.com > ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] App Factory Tier Implementation
Hi, I have few questions on above user stories, 1. How* "setup Eng"* define base currency for this? (USD, LKR) 2. Do we have any plan on specifying regions? 3. Are we planning to provide any REST APIs for this? (AFAIK we are not planning to have any payment modules in AF side. so probably we need to have API for integrate with another app (ex: cloud Mgt App) ) Thank you,. Regards, *Dakshika Jayathilaka* PMC Member & Committer of Apache Stratos Senior Software Engineer WSO2, Inc. lean.enterprise.middleware 0771100911 On Mon, Dec 14, 2015 at 9:37 AM, Nadeeshani Pathirennehelage < nadeesha...@wso2.com> wrote: > Hi All, > We are hoping to implement the tier implementation for the AppFactory. > Tier is the subscription plan which is selected by the organization admin > for the organization. > >1. > >AF Set Up Engineer should be able to define Tiers (free/paid v1/ paid >v2). >2. > >AF Set Up Engineer should be able to define Container Specs. >(t2.small/ t2.medium/ m2.small ) >3. System should display each Subscription Plans ( Free / Paid v1 / >paid v2) to the Organization Admin(Tenant) to choose a suitable plan for >the organization. >4. > >Organization Admin(Tenant) should be able to upgrade the subscription >plan for the organization. >5. System should display the each Container Specs Type( >Small/medium/large) with its features such as CPU, memory, storage to all >tenants. >6. > >Organization Admin(Tenant) should be able to choose new Container >Specs ( small , large , medium ) to the existing subscription plan. >Organization members should use those Container Spec. >7. > >Organization Admin(Tenant) should be able to remove Container Specs ( >small , large , medium ) from the existing subscription plan. >8. System should be able to view the details such as Plan Type, list >of Container Specs which is running and information of each Container Spec, >of a given Organization. > > > Table structure is given below. > > > > > *These tables are filled with just reference values.* > The above plan table can be expanded with more columns. > > The above table structure will be useful for the administration to > develop applications for configuring the tiers. Moreover it will be useful > to render the subscription plan to the end users through UI. > > Would appreciate it if you could give your suggestions and comments on > this. > Thanks, > Nadeeshani > > -- > Pathirennehelage Nadeeshani > Software Engineering Intern : WSO2 Inc > Mobile : +94 (0) 716 545223 > nadeesha...@wso2.com > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Permission model for WSO2 GReg Publisher
Hi, I have few suggestions on this. 1. IMO we need to merge all edit related actions to one section + Need to order the action bar with proper priority 2. In UI *Public to everyone *and *Public to internal users *do not showing the proper separation between their domains. we need to use intuitive wording including the permission that we are assigning be default. 3. IMO Once you add any role from the list, we need to remove added role from existing dropdown, otherwise user will think that they can add it again. 4. I think its good to provide some descriptive message to show how this permissions will effect on each role. (AFAIK we are providing hierarchical permission model for this, so we need to educate user on this) Just my two cents. :) Regards, *Dakshika Jayathilaka* PMC Member & Committer of Apache Stratos Senior Software Engineer WSO2, Inc. lean.enterprise.middleware 0771100911 On Mon, Oct 26, 2015 at 2:11 PM, Mushthaq Rumy <musht...@wso2.com> wrote: > Hi all, > > I'm going to implement a permission model for the GReg publisher which the > scenario is somewhat similar to the permission model in the management > console. > > There are some issues in the permission model of the management console. > > 1. The CRUD operation semantic is not well defined. > Eg: A role which has *write* permission might not have *read* > permission > > 2. A complex matrix grid of permission which causes user unfriendliness. > > I'm planning to fix these issues in the permission model for the GReg > publisher. The UI wireframe and the flow of the model will be as follows. > > 1. The user will be able to navigate to the permission screen by clicking > the *Permissions *tab on the top of the screen as shown below. > > [image: Inline image 2] > > 2. The user will be able to restrict the resource with *read only* > permission to all the internal users by checking the *Public to internal > users *option. > > [image: Inline image 1] > > 3. The user will be able to share the resource with *read only* > permission to all the public users by clicking the *Public to everyone * > option. > > [image: Inline image 2] > > 4. The user will be able to share the resource with other roles by > checking the *Share with other roles *option, selecting the role to share > and selecting the permission to give the selected role. > > [image: Inline image 3] > [image: Inline image 3] > > 5. The user will be able to remove the added permissions by clicking the *x > *link of a particular permission. > > Are there any improvements i can make to the above design. Appreciate your > suggestions. > > Thanks & Regards, > > -- > Mushthaq Rumy > *Software Engineer* > Mobile : +94 (0) 779 492140 <%2B94%20%280%29%20773%20451194> > Email : musht...@wso2.com > WSO2, Inc.; http://wso2.com/ > lean . enterprise . middleware. > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Client-Side validation for Enterprise store Publisher
Hi, AFAKI we need to think about multiple scenarios before we incorporate third party library into ES. Validation Scenarios: 1. Bind HTML5 type based validation 2. Multiple Custom Error message support per field 3. Dependent validation 4. Ajax validation onChange 5. Support for pattern based validation(Regx) 6. Localization support IMHO we need to fulfill most of above scenarios in general use. Shall we do a POC first? WDYT? Regards, *Dakshika Jayathilaka* PMC Member Committer of Apache Stratos Software Engineer WSO2, Inc. lean.enterprise.middleware 0771100911 On Fri, Apr 17, 2015 at 10:26 AM, Rajeenthini Satkunam rajeenth...@wso2.com wrote: Hi all, As per discussions, I would like to use JQuery validation plugin current version*:* 1.13.1 to client-side validations for Enterprise Store Publisher.JQuery validation plugin is licensed by MIT.So can anyone please advice me on can I proceed this task with using JQuery validation plugin? On Thu, Apr 9, 2015 at 1:39 PM, Rajeenthini Satkunam rajeenth...@wso2.com wrote: Hi herrmann, Thanks for your suggestion.As well as now I am only concerning most on the client-side validation and user experience.So I have proposed the above design.I will look into this link that you have provide well. On Wed, Apr 8, 2015 at 10:50 PM, Manfred Herrmann herrmann.manf...@googlemail.com wrote: hi Rajeenthini, the proposed jquery-validation would a realy helpful feature. But even more helpful would it be to validate on client-side in sync with server-side-validation. The data would be secure and consistent through server-side-validation. And at the same time the user experience would be great. In jaggeryjs framework codebase there are rhino and hostobjects used. Would it not a good idea to try using jquery-validation for server-side validation and sync the rules and methods to the client? The development workflow could like: 1. client-side development and test cycle 2. deploy on jaggery-server-side and test client+server-side validation What do you think? best regards Manfred e.g. some thoughts about client-/server-side validation from: http://blogs.lessthandot.com/index.php/webdev/client-side-vs-server-side-validation-in-web-applications/ Client-Side But when we look at how well it achieves the purpose, we find it has a lot of gaps: - Yes – It prevents bad values for users with good intent - Yes – It helps the good intent user correct their value without the overhead of a server round-trip - No – It prevents bad values when a script fails to load (like jQuery) - No – It prevents bad values as a result of malicious editing of the web form (developer tools) - No – It prevents bad values submitted directly to the endpoint (ex: Cross-Site Request Forgery https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29 ) - No – It prevents bad values when accessed in frames https://www.owasp.org/index.php/Cross_Frame_Scripting - No – It prevents bad values when data is altered via aMan-in-the-middle attack https://www.owasp.org/index.php/Man-in-the-middle_attack Server-Side So how does this stack up against the client-side method? - Yes – It prevents bad values for users with good intent - No – It helps the good intent user correct their value without the overhead of a server round-trip - Yes – It prevents bad values when a script fails to load (like jQuery) - Yes – It prevents bad values as a result of malicious editing of the web form (developer tools) - Yes – It prevents bad values submitted directly to the endpoint (ex: Cross-Site Request Forgery https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29 ) - Yes – It prevents bad values when accessed in frames https://www.owasp.org/index.php/Cross_Frame_Scripting - Yes – It prevents bad values when data is altered via a Man-in-the-middle attack https://www.owasp.org/index.php/Man-in-the-middle_attack 2015-04-08 6:53 GMT+02:00 Rajeenthini Satkunam rajeenth...@wso2.com: Hi all, *purpose Research* I am currently working on a task that do client-side validation for the Enterprise Store - Publisher.As for now we have server-side validation by asset RXT. For example it checks whether the field is required or readonly as well as validation for URL.I would like to propose a design for pluggable client-side validation using JQuery validator. JQuery validation plugin makes simple client-side form validation easy and gives plenty of customization options. Advantages of JQuery validation plugin - Set of validation methods - Default error messages - It's providing API for writing our own methods - I18n support -(Error messages can be translated into 37 other languages) *Proposed Design view* - Include another property called client-side-validation in asset.js
Re: [Architecture] [App Factory] Upgrading Font Awesome to 4.2.0
Hi, If you follow the patterns that changes on 4.2.0, you can do your migration work with less effort. Main class is change to icon-* - fa fa-*. check this migration guide provided by font awesome https://github.com/FortAwesome/Font-Awesome/wiki/Upgrading-from-3.2.1-to-4 for additional class changes. Thank you, *Dakshika Jayathilaka* Software Engineer WSO2, Inc. lean.enterprise.middleware 0771100911 On Wed, Oct 22, 2014 at 4:06 PM, Amalka Subasinghe ama...@wso2.com wrote: Hi, Currently App Factory uses Font Awesome 3.2.1 old version. Need to upgrade to 4.2.0 [1] which is the latest version to get new icons to the App Factory. [1] http://fortawesome.github.io/Font-Awesome/ [2] https://wso2.org/jira/browse/APPFAC-2592 Thanks Amalka ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [App Factory] Upgrading Font Awesome to 4.2.0
AFAIK your approach is not good. Font Awesome is third party library that we are using. Also we are not tracking or maintaining any fork on it. If you change CSS, other users may get confused whether its a older version or new one. Recommended way is to change our code base instead of changing code on third party library. Regards, *Dakshika Jayathilaka* Software Engineer WSO2, Inc. lean.enterprise.middleware 0771100911 On Thu, Oct 23, 2014 at 8:31 AM, Amalka Subasinghe ama...@wso2.com wrote: Thanks Dakshika, Here, I changed the fa-* part to icon-* in .css file. So I could do this with minimum changes without changing the usage of icons in *.jag files Thanks Amalka On Thu, Oct 23, 2014 at 6:27 AM, Dakshika Jayathilaka daksh...@wso2.com wrote: Hi, If you follow the patterns that changes on 4.2.0, you can do your migration work with less effort. Main class is change to icon-* - fa fa-*. check this migration guide provided by font awesome https://github.com/FortAwesome/Font-Awesome/wiki/Upgrading-from-3.2.1-to-4 for additional class changes. Thank you, *Dakshika Jayathilaka* Software Engineer WSO2, Inc. lean.enterprise.middleware 0771100911 On Wed, Oct 22, 2014 at 4:06 PM, Amalka Subasinghe ama...@wso2.com wrote: Hi, Currently App Factory uses Font Awesome 3.2.1 old version. Need to upgrade to 4.2.0 [1] which is the latest version to get new icons to the App Factory. [1] http://fortawesome.github.io/Font-Awesome/ [2] https://wso2.org/jira/browse/APPFAC-2592 Thanks Amalka ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Amalka Subasinghe WSO2 Inc. Mobile: +94 77 9401267 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] IS statistics dashboard
Hi, +1 for Chanakas point on last 24 hour default data showing. I'm not sure why we are having users dropdown. What is the user story for that? AFAIK we need to add search functionality on filtering data. ex: check details by IP Regards, *Dakshika Jayathilaka* Software Engineer WSO2, Inc. lean.enterprise.middleware 0771100911 On Mon, Oct 6, 2014 at 12:34 PM, Malintha Fernando malint...@wso2.com wrote: Hi, I am working to create a dashboard for IS to display service statistics. The dashboard is supposed to display service access information, success/failure ratios and other inherent informations to each service. Initially we are planned to make it available for authenticationAdmin service. Herewith, I am sending the dashboard UI mockups for authenticationAdmin service.[1] The overall solution architecture consists of an axis2 handler to log axis2 service statistics and a tomcat valve to log other services (oauth2, samlsso, passivests, openid). Log appender will publish them to BAM and analysed statistics will be shown on the IS dashboard. [1] https://moqups.com/malinth...@gmail.com/p6kjuONM/p:a77f637d2 Thank you, -- *Malintha Fernando* Software Engineer Intern, WSO2(Lanka) Pvt. Ltd. Student Member, IEEE (MIE - 92428359) Undergraduate, Faculty of Information Technology University of Moratuwa. Mobile : 071 8874922 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] BAM Log monitoring for Cloud
Is there any specific reason for using jqplot? AFAIK platform wide, we are using flotchart lib[1] due to advance customization capabilities. 1. http://www.flotcharts.org/ *Dakshika Jayathilaka* Software Engineer WSO2, Inc. lean.enterprise.middleware 0771100911 On Wed, Sep 24, 2014 at 2:48 PM, Gimantha Bandara giman...@wso2.com wrote: Hi All, Currently I am working on the Front end. These were developed keeping Kibana as the reference. Currently the UI supports the following tasks. 1. Setting the refresh rate ( Refresh the logging graph and the log table / Log view )* 2. Setting the Time range ( custom time range or in the format of ''Last 5 min, Last 10 mins...etc) * 3. Searchbox for searching ( Queries will be regex or Lucene ) 4. Filters (For searching) 5. Log graph ( hits per time) 6. Filters for log table/view 7. Log table view (in progress) 8. Micro panel which is similar to Kibana micro panel (in progress) The graph is created using jqplot[1] library. So the graph support all the features jqplot offers. Other UIs are based on JQuery/JQueryUI[2] The Micro Panel will be developed using Bootstrap[3]. Note that the theme used for the UI can be changed and the log table is still in progress. Currently the UI is integrated with ElasticSearch to view real log data. Here are some screenshots of the current UIs. Update-24.09.2014 https://docs.google.com/a/wso2.com/folderview?id=0B7luxEF9AEBxSHc3aEI3YUxYRVkusp=drive_web [1] http://www.jqplot.com/ [2] https://jquery.org/projects/ [3] http://getbootstrap.com/javascript/ -- Gimantha Bandara Software Engineer WSO2. Inc : http://wso2.com Mobile : +94714961919 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Storage of asset resources in the ES
Hi, IMO we need mechanism to store assets on external locations as wel. (ex: dropbox, fileshare ) most of the time users do not want to waste their bandwidth on downloadable stuff. but in this case we need to implement verification mechanism as wel. (SHA or MD5 hash for linked files) WDYT? Regards, *Dakshika Jayathilaka* Software Engineer WSO2, Inc. lean.enterprise.middleware 0771100911 On Tue, Aug 12, 2014 at 5:53 PM, Sameera Medagammaddegedara samee...@wso2.com wrote: Hi Everyone, *Current State:* - All the resources of an asset are stored in a database(e.g. images and pdfs) - The embedded H2 database is used as the default data source - CRUD operations are performed using an intermediate layer that abstracts out the complexities of dealing with different database types - The business logic deals with an interface that uses get and put methods to access the storage layer - All resources are served from a single endpoint that is used to control access based on the state of the asset that owns the resource *Problems with the current implementation* - The need to test and support the storage implementation across databases other than H2 and MYSQL - The need to replicate tenancy within the database schema - The need to enforce access control logic in the endpoint used to serve the resources *Proposed Solution* - Store and serve the resources using the registry - *Advantages:* - There will not be any need to support multiple database types at the ES level - The use of registry roles to control access to the resources - *Open Questions:* - Is it prudent to serve content from the registry? Thank You, Sameera -- Sameera Medagammaddegedara Software Engineer Contact: Email: samee...@wso2.com Mobile: + 94 077 255 3005 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] HTTP monitoring dashboard UXD for AS
@nuwan: Not really. this will use on AS with BAM support. Current UES doesn't support for custom level grid and tabs. so above app will not totally based on current UES. but i'm planning to develop the way that we can extend it with next UES release. *Dakshika Jayathilaka* Software Engineer WSO2, Inc. lean.enterprise.middleware 0771100911 On Fri, Aug 1, 2014 at 7:30 AM, Ruchira Wageesha ruch...@wso2.com wrote: Hi Dakshika, What I meant is, there is something wrong with the green popup, which doesn't match with the rest. i.e. Several edges have rounded corners and several aren't. Sometimes, if you get rid of rounded edges of the popped up menu and expand it to the full width of the left vertical bar, then that would be good IMO. /Ruchira On Fri, Aug 1, 2014 at 12:50 PM, Dakshika Jayathilaka daksh...@wso2.com wrote: @ruchira: by default it will load with collapsible left side bar. On that view sub menus will list under same main category. screen 3 implies the view on collapsed option. on that you can see the inner content by mouse hover. check below image for detail view on this.. *Dakshika Jayathilaka* Software Engineer WSO2, Inc. lean.enterprise.middleware 0771100911 On Fri, Aug 1, 2014 at 6:41 AM, Chathura Dilan chathu...@wso2.com wrote: Great!, Does Ruchira mean expanding that whole column and showing the menu when clicking the icons instead of the popup menu? On Fri, Aug 1, 2014 at 12:02 PM, Ruchira Wageesha ruch...@wso2.com wrote: Really nice Daskshika. One small thing from me. i.e. I prefer if you can do something with the menu popped up in the third image. Personally, I feel something wrong with that, though I am not exactly clear about that :). On Thu, Jul 31, 2014 at 4:59 PM, Dakshika Jayathilaka daksh...@wso2.com wrote: Hi, I came up with UXD for HTTP monitoring dashboard user experience aspects, based on[1], [2], [3]. Current target group would be DevOps, Developers, CIO and can be extensible. UXDs are based on HCI major principles, usability and human cognition. Screen Designs: *1. HTTP monitoring dashboard: *Mainly primary dashboard includes application vice summarized data including some critical data. Color blend on main metro set focus to total request and error section. Inside each metro block guides user eye into important data value within the block. *2.App dashboard: *this includes application based data as a summary. when you click on each section you can reach into next extended details page. *3. Extended Data: *this extended view may differ depending on the App dashboard selection. *General Considerations*: Top navigation may include user specific data and Application based data. Left Sidebar navigation is collapsible and it would helps to create more spaces for the data pixels. Comments are welcome. [1] mail: [Training Project] Progress Update - AS HTTP Monitoring with BAM [2] mail: [Architecture] BAM Based monitoring solution for WSO2 platform - Unification proposal [3] mail: ASBAM application and server monitoring Monitoring Parameters Thank you, Regards, *Dakshika Jayathilaka* Software Engineer WSO2, Inc. lean.enterprise.middleware 0771100911 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Ruchira Wageesha**Associate Technical Lead* *WSO2 Inc. - lean . enterprise . middleware | wso2.com http://wso2.com* *email: ruch...@wso2.com ruch...@wso2.com, blog: ruchirawageesha.blogspot.com http://ruchirawageesha.blogspot.com, mobile: +94 77 5493444 %2B94%2077%205493444* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Regards, Chatura Dilan Perera *(Senior Software Engineer** - WSO2 Inc.* * [Mobile])* www.dilan.me ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Ruchira Wageesha**Associate Technical Lead* *WSO2 Inc. - lean . enterprise . middleware | wso2.com http://wso2.com* *email: ruch...@wso2.com ruch...@wso2.com, blog: ruchirawageesha.blogspot.com http://ruchirawageesha.blogspot.com, mobile: +94 77 5493444 %2B94%2077%205493444* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Connector:Magento
Sales Order Credit Memo is important functionality, why you always removing it. :( *Dakshika Jayathilaka* Software Engineer WSO2, Inc. lean.enterprise.middleware 0771100911 On Mon, Jun 16, 2014 at 5:12 PM, Rasika Hettige rasi...@gmail.com wrote: Hi All When we go through the final method list, we thought that following methods under Sales Order Invoice should also be included as they add a significant value to version 1. getInvoiceInfo - Retrieve information about the invoice createInvoice - Create a new invoice for an order captureInvoice - Capture an invoice cancelInvoice - Cancel an invoice Thanks Regards Rasika -- View this message in context: http://wso2-oxygen-tank.10903.n7.nabble.com/Connector-Magento-tp97825p98222.html Sent from the WSO2 Architecture mailing list archive at Nabble.com. ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Introducing JSR-223 into Jaggery along with Nashorn Support
+1 for Nashron integration. I think we need give some priority to Package manager. AFAIK nodejs[1] get huge demand and community support due to NPM[2] and it would be great to have similar Avatar.js[3]. [1] nodejs.org [2] https://www.npmjs.org/ [3] https://avatar-js.java.net/ *Dakshika Jayathilaka* Software Engineer WSO2, Inc. lean.enterprise.middleware 0771100911 On Sun, Jun 1, 2014 at 12:58 PM, Ruchira Wageesha ruch...@wso2.com wrote: Hi All, We have started the integration of JSR-223 i.e. javax.script API with Jaggery. Sorry for the lengthy mail, but this is just to share the status and get your all kinds of feedbacks. A Jaggery fork and a distribution with the following improvements can be found at [1] and [2] respectively. In case you want to try this out before sharing your feedbacks, you can download a Jaggery distribution with all the above implementations at [2]. It consists of 5 demo apps. (At the moment, this has been tested only on linux/mac and you will have to run this either on JDK 7 or 8. As JDK 6 supports only an older version of ECMAScript, this pack will not work. But in order to get the support even on JDK 6, we will have to pack the JSR-223 rhino implementation with a rhino 1.7 version, following a similar way described at [7]) With the integration with JSR-223, we had to and thought to do a few changes and improvements to Jaggery which will be detailed below. BUT, please note that, every existing Jaggery application will work as it is, independent of those improvements. i.e. With a version field in jaggery.conf, we internally decide, whether to go with the newer version. *Key Decisions* 1. JSR-223 support - With this, Jaggery will use Nashorn from JDK8 onwards and will fallback to JDK's embeded Rhino version with JDK7 or below. 2. Saying good bye for hostobjects - Hostobjects are a concept of Rhino and it was needed to follow certain conventions when you write your hostobjects. With JSR-223, we cannot have it anymore. But, instead of that, you can refactor only the hostobject *.java class into *.js file which contains the Java code and plug it. 3. Dropping E4X support - E4X was an extension to ECMAScripts and usage of E4X is being deprecated in many places. Also, AFAIK, there is no support for E4X in nashorn. This will be replaced by a Axiom/DOM like modules. i.e. without altering the spec. 4. Except the bare minimal, everything else is separated into commonjs modules - This will give much more flexibility and extendability for Jaggery. i.e. In order to extend Jaggery, developers don't need to be Java developers anymore 5. Introduction of app.server() method - In the current version, routing mechanism has been implemented by Jaggery core and there is no way to intercept that. This makes it harder to write cooler modules for Jaggery, such as express, connect for node. Using app.server(), Jaggery core delegates request serving to a single callback. But, via that callback, users can call their own routing modules and do whatever they want. You can even implement the current *.jag model, on top of app.server()[refer demo3]. Also, we have written an express like routing framework which can be used to define REST APIs very easily through Jaggery. This will be a good alternative for JAX-RS developers too. 6. Servlet 3.0 Async support - Another key feature is utilizing Async servlet support. So, concurrency will not be restricted by the available thread count anymore. 7. CommonJS module system - At the moment, Jaggery has its own module system. Instead of that, we though of going ahead with commonjs module specification. With this, commonjs compliant modules will be able to use within Jaggery. i.e. Any node module which doesn't depend on node core APIs, can be used in Jaggery as well, without doing any change. 8. Module versioning and nested module support - Another improvement is, adding module versioning support for Jaggery modules. i.e. x app(or module) can use y1 version of y module, while another z app(or module) can use y2 without conflicting each other. For this too, we are also using package.json as per the commonjs specification 9. Support for deploying directly on top of tomcat - With the above Jaggery core minimisations, a Jaggery app can be even deployed on top of tomcat, subjecting to a WEB-INF directory which contains jaggery core jars and web.xml 10. Improved command line tool - clamshell-cli based command line tool with history support etc. With this, we expect people to write more command line tools such as built tools, package managers etc. using Jaggery *Demo Apps* 1. https://github.com
Re: [Architecture] Connector:Magento
Magnto REST doesn't cover most important sections like sales in detail, why can't we try their SOAP?? it cover almost everything http://www.magentocommerce.com/api/soap/introduction.html *Dakshika Jayathilaka* Software Engineer WSO2, Inc. lean.enterprise.middleware 0771100911 On Wed, Jun 4, 2014 at 12:40 PM, Rasika Hettige rasi...@gmail.com wrote: *Introduction* Magento is an open source e-commerce web application. It is a content management system (CMS) based on PHP and MySQL for web hosting service, which was built using parts of the Zend Framework.It provides full support for object-oriented programming and Model-View-Controller (MVC) architecture. *API (REST)* http://www.magentocommerce.com/api/rest/introduction.html *Magento Connector Summary* • Connector Name: magento-connector-1.0.0 • Version: 1.0.0 • Technology: REST *Authentication* Magento REST API uses 3-legged OAuth 1.0a protocol to authenticate the application to access the Magento service. *Methods Selected:* *Products* *createProduct* - Create a new Product. *updateProduct* - Update an existing Product. *deleteProduct* - Delete an existing Product. *listProducts* - List products existing within the instance. *getProduct* - Get details for a single product. *Product Categories* *getProductCategory *- Get categories a specific product falls under. *addCategoryToProduct *- Add a category to a specific product. *deleteCategoryFromProduct *- Remove a product from a category. *Product Images* *getProductImages *- Retrieves details for images associated with a product. - Note: This method covers the functionality of *get*, *[store_image]get*, *[single_image]get* and *[store_image/single_image]get* *addProductImage* - Adds a single image to a product. - Note: This method also covers the functionality of *add* and * [store_image]add* *updateProductImage *- Updates details (and content) of a single image assigned to a product. - Note: This method also covers the functionality of * [single_image]update* and *store_image/single_image]update* deleteProductImage - Deletes a single image assigned to a product. Note: This method also covers the functionality of [single_image]delete and [store_image/single_image]delete *Orders* *listOrders *- Gets a list of orders. *getOrder *- Gets details of a single order by ID. *Order Addresses* *getOrderAddresses* - Retrieve information about billing and shipping addresses of the required order. - Note: This method also covers the functionality of *get* , *[shipping]get* and *[billing]get* *Order Comments* *getOrderComments* - Get comments assigned to an order. *Order Items* *getOrderItems* - Get items for an order. *Inventory* *listStockItems *- Retrieve a list of existing stock items. *getStockItem *- Get details of a single stock item by ID. *updateStockItem *- Update details for a single stock item. *Customer Addresses* *listCustomerAddresses *- Lists addresses defined for a customer. *addCustomerAddress *- Adds a new address for a customer. *updateCustomerAddress *- Updates a single customer address by address ID. *deleteCustomerAddress *- Deletes a single customer address. *Customers* *getCustomer* - Get details of a single customer *createCustomer * - Creates a new Customer *updateCustomer * - Updates details of a single customer *deleteCustomer * - Deletes a single customer. *Methods not selected:* *Product Websites* *get ,add [Website Assignment with Product Data Copying]add ,[Multi-Website Assignment]add ,[Multi-Website Assignment with Product Data Copying]post*, and *delete* methods disregarded from the first version as they are supporting one time entry functionalities. *[single]get *- Functionality of this method is covered under listOrders method. *[single]get* - Functionality of this method is covered under listCustomerAddresses method. *listCustomers* - This method is ignored from the first version as it has a less business value than the getCustomer method . Thanks Regards Rasika -- View this message in context: http://wso2-oxygen-tank.10903.n7.nabble.com/Connector-Magento-tp97825.html Sent from the WSO2 Architecture mailing list archive at Nabble.com. ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
