Re: Invitation: Goose.js and Absolute.js training @ Tue Dec 3, 2013 1pm - 2pm (dulitha@wso2.com)

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Invitation: Goose.js and Absolute.js training @ Tue Dec 3, 2013 1pm - 2pm (dulitha@wso2.com)

Nuwan Bandara-2
Hi Chan,

We need to review the new security stuff you did for Goose.js (the routing library) and also if we are doing any new jaggery application, we MUST follow caramel as that is the standard. If there are improvements lets do it to Caramel. We should not use two libraries in the platform as it will be a maintenance nightmare. So am -1 on developing applications in Absolute. If Caramel is missing functionalities that you desire, please add them to Caramel. 

Regards,
/Nuwan


On Sun, Dec 1, 2013 at 11:45 PM, [hidden email] <[hidden email]> wrote:

Goose.js and Absolute.js training

Goose is a javascript framework for quickly writing APIs. Absolute is a front-end controller framework for jaggery for that can be used to build MVC type applications.

Goose.js - https://github.com/dulichan/goose.js
Absolute.js - https://github.com/dulichan/absolute.js

When
Tue Dec 3, 2013 1pm – 2pm Colombo
Where
3rd Floor Kernel Meeting room (map)
Calendar
[hidden email]
Who
[hidden email] - organizer
Shanmugarajah Sinnathamby
Kasun Dananjaya Delgolla
Gayan Gunawardana
Krishanthi Samarasinghe
Harshan Liyanage
Dilshan Edirisuriya
Niranjan Karunanandham
Dilan Jayakody
WSO2 Training Group

Going?   Yes - Maybe - No    more options »

Invitation from Google Calendar

You are receiving this courtesy email at the account [hidden email] because you are an attendee of this event.

To stop receiving future notifications for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.




--
Thanks & Regards,

Nuwan Bandara
Technical Lead; 
WSO2 Inc. 
lean . enterprise . middleware |  http://wso2.com 
blog : http://nuwanbando.com; email: [hidden email]; phone: +1 812 606 7390


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: Invitation: Goose.js and Absolute.js training @ Tue Dec 3, 2013 1pm - 2pm (dulitha@wso2.com)

Dulitha Wijewantha
Hi Nuwan,
My comments are inline. What I am proposing - is to build a fully functional front-end controller rather than just another template renderer. Let's have a discussion regarding this. I am also refactoring Absolute to provide capability to override how the pattern matching is done. This training is for anyone who is interested in these frameworks- mainly because they are pragmatic. 

On Mon, Dec 2, 2013 at 6:18 PM, Nuwan Bandara <[hidden email]> wrote:
Hi Chan,

We need to review the new security stuff you did for Goose.js (the routing library)

+1 for reviewing security of Goose.js. 
 
and also if we are doing any new jaggery application, we MUST follow caramel as that is the standard.
-1 for Caramel - below are my reasons 
  • Caramel is not really a framework. It's a template engine that does dynamic engine. It's an overkill for applications (that's not meant for overriding) 
  • A front end controller is required for an application due authentication, custom controller actions, monitoring etc.
  • Caramel enforce carmel objects into the controller jags 

If there are improvements lets do it to Caramel.
-1 reasons for not improving Caramel are -
  • Caramel is all together a different concept. It's not about a front-end controller. It's about a dynamic template engine 
  • Caramel is kind of procedural where you have to evoke it from controllers
  • Caramel can be used in ways the developer wants. It's exactly opposing the idea of a framework. A framework exert certain things over developer. Caramel makes everyone write their own version of MVC (take Store and Publisher for an example.
 
We should not use two libraries in the platform as it will be a maintenance nightmare. So am -1 on developing applications in Absolute. If Caramel is missing functionalities that you desire, please add them to Caramel. 
I am suggesting to drop Caramel support and build a fully functional front-end controller. Caramel was built for something else and it shouldn't be continued because it's not really needed if you really look at it. Why - I am explaining below -

Why do you need a framework - You want to run the X logic on the Y request and display the Z representation to the user. In the world of frameworks - X is a controller, Y is the request, and Z is a display (view). Absolute simply allows you to match a controller to a view based on the user's request. The way you do it is up to you. You can use a conventional base approach as a pattern matching algorithm or a configuration approach.  The underlying framework requirement is just mapping logic to request and rendering representations. 


Regards,
/Nuwan


On Sun, Dec 1, 2013 at 11:45 PM, [hidden email] <[hidden email]> wrote:

Goose.js and Absolute.js training

Goose is a javascript framework for quickly writing APIs. Absolute is a front-end controller framework for jaggery for that can be used to build MVC type applications.

Goose.js - https://github.com/dulichan/goose.js
Absolute.js - https://github.com/dulichan/absolute.js

When
Tue Dec 3, 2013 1pm – 2pm Colombo
Where
3rd Floor Kernel Meeting room (map)
Calendar
[hidden email]
Who
[hidden email] - organizer
Shanmugarajah Sinnathamby
Kasun Dananjaya Delgolla
Gayan Gunawardana
Krishanthi Samarasinghe
Harshan Liyanage
Dilshan Edirisuriya
Niranjan Karunanandham
Dilan Jayakody
WSO2 Training Group

Going?   Yes - Maybe - No    more options »

Invitation from Google Calendar

You are receiving this courtesy email at the account [hidden email] because you are an attendee of this event.

To stop receiving future notifications for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.




--
Thanks & Regards,

Nuwan Bandara
Technical Lead; 
WSO2 Inc. 
lean . enterprise . middleware |  http://wso2.com 
blog : http://nuwanbando.com; email: [hidden email]; phone: <a href="tel:%2B1%20812%20606%207390" value="+18126067390" target="_blank">+1 812 606 7390




--
Chan (Dulitha Wijewantha) 
Software Engineer - Mobile Development
WSO2Mobile 
Lean.Enterprise.Mobileware
  ~Email       [hidden email]
  ~Mobile     +94712112165
  ~Website   dulithawijewantha.com
  ~Blog         blog.dulithawijewantha.com
  ~Twitter     @dulitharw

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: Invitation: Goose.js and Absolute.js training @ Tue Dec 3, 2013 1pm - 2pm (dulitha@wso2.com)

Nuwan Bandara-2
Hi Dulitha,

We have had this debate over and over. What am trying to point out here is that we simply CANNOT have another way of writing jaggery apps. If we need improvements to Caramel please go ahead and contribute, don't create a new one that serves ur purpose. Caramel was there for sometime and APIM / UES / Store are build on that pattern. Front controller is sometimes good and sometime not so good, people will need multiple controller patterns at times. So please dont rely on just one pattern. 

In a web app framework there are more things to think about, not just the controllers, most of the elements are well thought and included to caramel. So please take a moment and try to understand the framework and improve it as you need, but dont invent a new thing just for your cause. and please think about the consistency when developing apps/components you cannot and should not just use random technologies here and there.

Regards,
/Nuwan


On Mon, Dec 2, 2013 at 11:48 AM, Dulitha Wijewantha <[hidden email]> wrote:
Hi Nuwan,
My comments are inline. What I am proposing - is to build a fully functional front-end controller rather than just another template renderer. Let's have a discussion regarding this. I am also refactoring Absolute to provide capability to override how the pattern matching is done. This training is for anyone who is interested in these frameworks- mainly because they are pragmatic. 

On Mon, Dec 2, 2013 at 6:18 PM, Nuwan Bandara <[hidden email]> wrote:
Hi Chan,

We need to review the new security stuff you did for Goose.js (the routing library)

+1 for reviewing security of Goose.js. 
 
and also if we are doing any new jaggery application, we MUST follow caramel as that is the standard.
-1 for Caramel - below are my reasons 
  • Caramel is not really a framework. It's a template engine that does dynamic engine. It's an overkill for applications (that's not meant for overriding) 
  • A front end controller is required for an application due authentication, custom controller actions, monitoring etc.
  • Caramel enforce carmel objects into the controller jags 

If there are improvements lets do it to Caramel.
-1 reasons for not improving Caramel are -
  • Caramel is all together a different concept. It's not about a front-end controller. It's about a dynamic template engine 
  • Caramel is kind of procedural where you have to evoke it from controllers
  • Caramel can be used in ways the developer wants. It's exactly opposing the idea of a framework. A framework exert certain things over developer. Caramel makes everyone write their own version of MVC (take Store and Publisher for an example.
 
We should not use two libraries in the platform as it will be a maintenance nightmare. So am -1 on developing applications in Absolute. If Caramel is missing functionalities that you desire, please add them to Caramel. 
I am suggesting to drop Caramel support and build a fully functional front-end controller. Caramel was built for something else and it shouldn't be continued because it's not really needed if you really look at it. Why - I am explaining below -

Why do you need a framework - You want to run the X logic on the Y request and display the Z representation to the user. In the world of frameworks - X is a controller, Y is the request, and Z is a display (view). Absolute simply allows you to match a controller to a view based on the user's request. The way you do it is up to you. You can use a conventional base approach as a pattern matching algorithm or a configuration approach.  The underlying framework requirement is just mapping logic to request and rendering representations. 


Regards,
/Nuwan


On Sun, Dec 1, 2013 at 11:45 PM, [hidden email] <[hidden email]> wrote:

Goose.js and Absolute.js training

Goose is a javascript framework for quickly writing APIs. Absolute is a front-end controller framework for jaggery for that can be used to build MVC type applications.

Goose.js - https://github.com/dulichan/goose.js
Absolute.js - https://github.com/dulichan/absolute.js

When
Tue Dec 3, 2013 1pm – 2pm Colombo
Where
3rd Floor Kernel Meeting room (map)
Calendar
[hidden email]
Who
[hidden email] - organizer
Shanmugarajah Sinnathamby
Kasun Dananjaya Delgolla
Gayan Gunawardana
Krishanthi Samarasinghe
Harshan Liyanage
Dilshan Edirisuriya
Niranjan Karunanandham
Dilan Jayakody
WSO2 Training Group

Going?   Yes - Maybe - No    more options »

Invitation from Google Calendar

You are receiving this courtesy email at the account [hidden email] because you are an attendee of this event.

To stop receiving future notifications for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.




--
Thanks & Regards,

Nuwan Bandara
Technical Lead; 
WSO2 Inc. 
lean . enterprise . middleware |  http://wso2.com 
blog : http://nuwanbando.com; email: [hidden email]; phone: <a href="tel:%2B1%20812%20606%207390" value="+18126067390" target="_blank">+1 812 606 7390




--
Chan (Dulitha Wijewantha) 
Software Engineer - Mobile Development
WSO2Mobile 
Lean.Enterprise.Mobileware
  ~Email       [hidden email]
  ~Mobile     <a href="tel:%2B94712112165" value="+94712112165" target="_blank">+94712112165
  ~Website   dulithawijewantha.com
  ~Blog         blog.dulithawijewantha.com
  ~Twitter     @dulitharw



--
Thanks & Regards,

Nuwan Bandara
Technical Lead; 
WSO2 Inc. 
lean . enterprise . middleware |  http://wso2.com 
blog : http://nuwanbando.com; email: [hidden email]; phone: +1 812 606 7390


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: Invitation: Goose.js and Absolute.js training @ Tue Dec 3, 2013 1pm - 2pm (dulitha@wso2.com)

venura
Hi Nuwan,

I'm new to jaggery world but while I was developing "my-identity" application for IS I found out some limitations in jaggery and Caramel.
What I needed was to implement a filter functionality just as in servlet filter. Purpose of the filter is described. When we have multiple pages and if some page should be restricted for some set of people based on the permissions, groups or some other factor, then we can intercept the request and validate within the filter. This is a basic requirement and it is pretty hard to implement that requirement in jaggery without adding a code segment to each page.

IMO we need to consider these kinds of existing features when implementing a new language. Yes as you mentioned, we need to improve the jaggery and Caramel instead of implementing functionality in separate places, but we should add these functionality since we are moving towards jaggery and caramel.

Regards,
Venura


On Tue, Dec 3, 2013 at 8:06 AM, Nuwan Bandara <[hidden email]> wrote:
Hi Dulitha,

We have had this debate over and over. What am trying to point out here is that we simply CANNOT have another way of writing jaggery apps. If we need improvements to Caramel please go ahead and contribute, don't create a new one that serves ur purpose. Caramel was there for sometime and APIM / UES / Store are build on that pattern. Front controller is sometimes good and sometime not so good, people will need multiple controller patterns at times. So please dont rely on just one pattern. 

In a web app framework there are more things to think about, not just the controllers, most of the elements are well thought and included to caramel. So please take a moment and try to understand the framework and improve it as you need, but dont invent a new thing just for your cause. and please think about the consistency when developing apps/components you cannot and should not just use random technologies here and there.

Regards,
/Nuwan


On Mon, Dec 2, 2013 at 11:48 AM, Dulitha Wijewantha <[hidden email]> wrote:
Hi Nuwan,
My comments are inline. What I am proposing - is to build a fully functional front-end controller rather than just another template renderer. Let's have a discussion regarding this. I am also refactoring Absolute to provide capability to override how the pattern matching is done. This training is for anyone who is interested in these frameworks- mainly because they are pragmatic. 

On Mon, Dec 2, 2013 at 6:18 PM, Nuwan Bandara <[hidden email]> wrote:
Hi Chan,

We need to review the new security stuff you did for Goose.js (the routing library)

+1 for reviewing security of Goose.js. 
 
and also if we are doing any new jaggery application, we MUST follow caramel as that is the standard.
-1 for Caramel - below are my reasons 
  • Caramel is not really a framework. It's a template engine that does dynamic engine. It's an overkill for applications (that's not meant for overriding) 
  • A front end controller is required for an application due authentication, custom controller actions, monitoring etc.
  • Caramel enforce carmel objects into the controller jags 

If there are improvements lets do it to Caramel.
-1 reasons for not improving Caramel are -
  • Caramel is all together a different concept. It's not about a front-end controller. It's about a dynamic template engine 
  • Caramel is kind of procedural where you have to evoke it from controllers
  • Caramel can be used in ways the developer wants. It's exactly opposing the idea of a framework. A framework exert certain things over developer. Caramel makes everyone write their own version of MVC (take Store and Publisher for an example.
 
We should not use two libraries in the platform as it will be a maintenance nightmare. So am -1 on developing applications in Absolute. If Caramel is missing functionalities that you desire, please add them to Caramel. 
I am suggesting to drop Caramel support and build a fully functional front-end controller. Caramel was built for something else and it shouldn't be continued because it's not really needed if you really look at it. Why - I am explaining below -

Why do you need a framework - You want to run the X logic on the Y request and display the Z representation to the user. In the world of frameworks - X is a controller, Y is the request, and Z is a display (view). Absolute simply allows you to match a controller to a view based on the user's request. The way you do it is up to you. You can use a conventional base approach as a pattern matching algorithm or a configuration approach.  The underlying framework requirement is just mapping logic to request and rendering representations. 


Regards,
/Nuwan


On Sun, Dec 1, 2013 at 11:45 PM, [hidden email] <[hidden email]> wrote:

Goose.js and Absolute.js training

Goose is a javascript framework for quickly writing APIs. Absolute is a front-end controller framework for jaggery for that can be used to build MVC type applications.

Goose.js - https://github.com/dulichan/goose.js
Absolute.js - https://github.com/dulichan/absolute.js

When
Tue Dec 3, 2013 1pm – 2pm Colombo
Where
3rd Floor Kernel Meeting room (map)
Calendar
[hidden email]
Who
[hidden email] - organizer
Shanmugarajah Sinnathamby
Kasun Dananjaya Delgolla
Gayan Gunawardana
Krishanthi Samarasinghe
Harshan Liyanage
Dilshan Edirisuriya
Niranjan Karunanandham
Dilan Jayakody
WSO2 Training Group

Going?   Yes - Maybe - No    more options »

Invitation from Google Calendar

You are receiving this courtesy email at the account [hidden email] because you are an attendee of this event.

To stop receiving future notifications for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.




--
Thanks & Regards,

Nuwan Bandara
Technical Lead; 
WSO2 Inc. 
lean . enterprise . middleware |  http://wso2.com 
blog : http://nuwanbando.com; email: [hidden email]; phone: <a href="tel:%2B1%20812%20606%207390" value="+18126067390" target="_blank">+1 812 606 7390




--
Chan (Dulitha Wijewantha) 
Software Engineer - Mobile Development
WSO2Mobile 
Lean.Enterprise.Mobileware
  ~Email       [hidden email]
  ~Mobile     <a href="tel:%2B94712112165" value="+94712112165" target="_blank">+94712112165
  ~Website   dulithawijewantha.com
  ~Blog         blog.dulithawijewantha.com
  ~Twitter     @dulitharw



--
Thanks & Regards,

Nuwan Bandara
Technical Lead; 
WSO2 Inc. 
lean . enterprise . middleware |  http://wso2.com 
blog : http://nuwanbando.com; email: [hidden email]; phone: <a href="tel:%2B1%20812%20606%207390" value="+18126067390" target="_blank">+1 812 606 7390




--
Senior Software Engineer

Mobile: +94 71 82 300 20


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: Invitation: Goose.js and Absolute.js training @ Tue Dec 3, 2013 1pm - 2pm (dulitha@wso2.com)

venura
Hi,

I was not aware that filter concept was removed from jaggery, but we need to have a proper alternative so we can full fill basic needs of a basic web application.

@Nuwan: Could you please give an example on how a controller should be implemented given that my application adheres the caramel standards? If we can come up with a proper way of doing this, it will save a lot of time.

Regards,
Venura


On Tue, Dec 3, 2013 at 10:55 AM, Gayan Gunawardana <[hidden email]> wrote:
Hi Venura,

We have discussed jaggery filter functionality few months back. You can find more information from [xacml with jaggery] mail thread in [hidden email]. We had the same requirement like how to implement Entitlement filter from jaggery side.

But the final conclusion was there are no filters in jaggery world, what you can do is, route all requests through one controller which will act as your filter 

I am totally +1 for considering these kind of existing features when implementing a new language.


On Tue, Dec 3, 2013 at 10:29 AM, Venura Kahawala <[hidden email]> wrote:
Hi Nuwan,

I'm new to jaggery world but while I was developing "my-identity" application for IS I found out some limitations in jaggery and Caramel.
What I needed was to implement a filter functionality just as in servlet filter. Purpose of the filter is described. When we have multiple pages and if some page should be restricted for some set of people based on the permissions, groups or some other factor, then we can intercept the request and validate within the filter. This is a basic requirement and it is pretty hard to implement that requirement in jaggery without adding a code segment to each page.

IMO we need to consider these kinds of existing features when implementing a new language. Yes as you mentioned, we need to improve the jaggery and Caramel instead of implementing functionality in separate places, but we should add these functionality since we are moving towards jaggery and caramel.

Regards,
Venura


On Tue, Dec 3, 2013 at 8:06 AM, Nuwan Bandara <[hidden email]> wrote:
Hi Dulitha,

We have had this debate over and over. What am trying to point out here is that we simply CANNOT have another way of writing jaggery apps. If we need improvements to Caramel please go ahead and contribute, don't create a new one that serves ur purpose. Caramel was there for sometime and APIM / UES / Store are build on that pattern. Front controller is sometimes good and sometime not so good, people will need multiple controller patterns at times. So please dont rely on just one pattern. 

In a web app framework there are more things to think about, not just the controllers, most of the elements are well thought and included to caramel. So please take a moment and try to understand the framework and improve it as you need, but dont invent a new thing just for your cause. and please think about the consistency when developing apps/components you cannot and should not just use random technologies here and there.

Regards,
/Nuwan


On Mon, Dec 2, 2013 at 11:48 AM, Dulitha Wijewantha <[hidden email]> wrote:
Hi Nuwan,
My comments are inline. What I am proposing - is to build a fully functional front-end controller rather than just another template renderer. Let's have a discussion regarding this. I am also refactoring Absolute to provide capability to override how the pattern matching is done. This training is for anyone who is interested in these frameworks- mainly because they are pragmatic. 

On Mon, Dec 2, 2013 at 6:18 PM, Nuwan Bandara <[hidden email]> wrote:
Hi Chan,

We need to review the new security stuff you did for Goose.js (the routing library)

+1 for reviewing security of Goose.js. 
 
and also if we are doing any new jaggery application, we MUST follow caramel as that is the standard.
-1 for Caramel - below are my reasons 
  • Caramel is not really a framework. It's a template engine that does dynamic engine. It's an overkill for applications (that's not meant for overriding) 
  • A front end controller is required for an application due authentication, custom controller actions, monitoring etc.
  • Caramel enforce carmel objects into the controller jags 

If there are improvements lets do it to Caramel.
-1 reasons for not improving Caramel are -
  • Caramel is all together a different concept. It's not about a front-end controller. It's about a dynamic template engine 
  • Caramel is kind of procedural where you have to evoke it from controllers
  • Caramel can be used in ways the developer wants. It's exactly opposing the idea of a framework. A framework exert certain things over developer. Caramel makes everyone write their own version of MVC (take Store and Publisher for an example.
 
We should not use two libraries in the platform as it will be a maintenance nightmare. So am -1 on developing applications in Absolute. If Caramel is missing functionalities that you desire, please add them to Caramel. 
I am suggesting to drop Caramel support and build a fully functional front-end controller. Caramel was built for something else and it shouldn't be continued because it's not really needed if you really look at it. Why - I am explaining below -

Why do you need a framework - You want to run the X logic on the Y request and display the Z representation to the user. In the world of frameworks - X is a controller, Y is the request, and Z is a display (view). Absolute simply allows you to match a controller to a view based on the user's request. The way you do it is up to you. You can use a conventional base approach as a pattern matching algorithm or a configuration approach.  The underlying framework requirement is just mapping logic to request and rendering representations. 


Regards,
/Nuwan


On Sun, Dec 1, 2013 at 11:45 PM, [hidden email] <[hidden email]> wrote:

Goose.js and Absolute.js training

Goose is a javascript framework for quickly writing APIs. Absolute is a front-end controller framework for jaggery for that can be used to build MVC type applications.

Goose.js - https://github.com/dulichan/goose.js
Absolute.js - https://github.com/dulichan/absolute.js

When
Tue Dec 3, 2013 1pm – 2pm Colombo
Where
3rd Floor Kernel Meeting room (map)
Calendar
[hidden email]
Who
[hidden email] - organizer
Shanmugarajah Sinnathamby
Kasun Dananjaya Delgolla
Gayan Gunawardana
Krishanthi Samarasinghe
Harshan Liyanage
Dilshan Edirisuriya
Niranjan Karunanandham
Dilan Jayakody
WSO2 Training Group

Going?   Yes - Maybe - No    more options »

Invitation from Google Calendar

You are receiving this courtesy email at the account [hidden email] because you are an attendee of this event.

To stop receiving future notifications for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.




--
Thanks & Regards,

Nuwan Bandara
Technical Lead; 
WSO2 Inc. 
lean . enterprise . middleware |  http://wso2.com 
blog : http://nuwanbando.com; email: [hidden email]; phone: <a href="tel:%2B1%20812%20606%207390" value="+18126067390" target="_blank">+1 812 606 7390




--
Chan (Dulitha Wijewantha) 
Software Engineer - Mobile Development
WSO2Mobile 
Lean.Enterprise.Mobileware
  ~Email       [hidden email]
  ~Mobile     <a href="tel:%2B94712112165" value="+94712112165" target="_blank">+94712112165
  ~Website   dulithawijewantha.com
  ~Blog         blog.dulithawijewantha.com
  ~Twitter     @dulitharw



--
Thanks & Regards,

Nuwan Bandara
Technical Lead; 
WSO2 Inc. 
lean . enterprise . middleware |  http://wso2.com 
blog : http://nuwanbando.com; email: [hidden email]; phone: <a href="tel:%2B1%20812%20606%207390" value="+18126067390" target="_blank">+1 812 606 7390




--
Senior Software Engineer

Mobile: <a href="tel:%2B94%2071%2082%20300%2020" value="+94718230020" target="_blank">+94 71 82 300 20




--
Gayan Gunawardana
Software Engineer; WSO2mobile Inc.; http://wso2mobile.com/
Blog: http://gayanj2ee.blogspot.com/



--
Senior Software Engineer

Mobile: +94 71 82 300 20


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: Invitation: Goose.js and Absolute.js training @ Tue Dec 3, 2013 1pm - 2pm (dulitha@wso2.com)

Dulitha Wijewantha

Hi all,

My comments are inline. Other than that I wrote a sample blogger app that’s there for Caramel in Absolute. It’s found at [1]. My point is - I am willing to talk why Caramel approach is incorrect and why we need a Front-end controller. But folks- you got to be willing to listen. 

[1] - https://github.com/dulichan/absolute-example


PS:- I removed the training group since it’s an internal one. 

Peace~



On Tue, Dec 3, 2013 at 11:09 AM, Venura Kahawala <[hidden email]> wrote:
Hi,

I was not aware that filter concept was removed from jaggery, but we need to have a proper alternative so we can full fill basic needs of a basic web application.

@Nuwan: Could you please give an example on how a controller should be implemented given that my application adheres the caramel standards? If we can come up with a proper way of doing this, it will save a lot of time.  
Regards,
Venura


On Tue, Dec 3, 2013 at 10:55 AM, Gayan Gunawardana <[hidden email]> wrote:
Hi Venura,

We have discussed jaggery filter functionality few months back. You can find more information from [xacml with jaggery] mail thread in [hidden email]. We had the same requirement like how to implement Entitlement filter from jaggery side.

But the final conclusion was there are no filters in jaggery world, what you can do is, route all requests through one controller which will act as your filter 

Ain't this the Front-end controller?
 

I am totally +1 for considering these kind of existing features when implementing a new language.


On Tue, Dec 3, 2013 at 10:29 AM, Venura Kahawala <[hidden email]> wrote:
Hi Nuwan,

I'm new to jaggery world but while I was developing "my-identity" application for IS I found out some limitations in jaggery and Caramel.
What I needed was to implement a filter functionality just as in servlet filter. Purpose of the filter is described. When we have multiple pages and if some page should be restricted for some set of people based on the permissions, groups or some other factor, then we can intercept the request and validate within the filter. This is a basic requirement and it is pretty hard to implement that requirement in jaggery without adding a code segment to each page.

IMO we need to consider these kinds of existing features when implementing a new language. Yes as you mentioned, we need to improve the jaggery and Caramel instead of implementing functionality in separate places, but we should add these functionality since we are moving towards jaggery and caramel.

Regards,
Venura


On Tue, Dec 3, 2013 at 8:06 AM, Nuwan Bandara <[hidden email]> wrote:
Hi Dulitha,

We have had this debate over and over. What am trying to point out here is that we simply CANNOT have another way of writing jaggery apps.

+1 for not having another way to writing jaggery apps. But I don't agree that way to be Caramel. 
 
If we need improvements to Caramel please go ahead and contribute, don't create a new one that serves ur purpose. Caramel was there for sometime and APIM / UES / Store are build on that pattern.

We have used Store and Publisher both and found out that both of them are pretty inconsistent. Maybe Store and Publisher makes Caramel looks complex but I check the blogger sample and found that it's too over complicated. 
 
Front controller is sometimes good and sometime not so good, people will need multiple controller patterns at times. So please dont rely on just one pattern. 

We need multiple controller patterns. But we need a front-end controller. 


In a web app framework there are more things to think about, not just the controllers, most of the elements are well thought and included to caramel. So please take a moment and try to understand the framework and improve it as you need, but dont invent a new thing just for your cause.

The reason why we built absolute is to make writing jaggery apps pragmatic. Caramel is not pragmatic. We can't improve something when both concepts are different like Template engine and Front-end controller.  
 
and please think about the consistency when developing apps/components you cannot and should not just use random technologies here and there.

Random technology? Caramel is random technology. Absolute build on framework concepts found in Rails, Node etc (http://addyosmani.github.io/backbone-fundamentals/#mvc-applied-to-the-web)


Regards,
/Nuwan


On Mon, Dec 2, 2013 at 11:48 AM, Dulitha Wijewantha <[hidden email]> wrote:
Hi Nuwan,
My comments are inline. What I am proposing - is to build a fully functional front-end controller rather than just another template renderer. Let's have a discussion regarding this. I am also refactoring Absolute to provide capability to override how the pattern matching is done. This training is for anyone who is interested in these frameworks- mainly because they are pragmatic. 

On Mon, Dec 2, 2013 at 6:18 PM, Nuwan Bandara <[hidden email]> wrote:
Hi Chan,

We need to review the new security stuff you did for Goose.js (the routing library)

+1 for reviewing security of Goose.js. 
 
and also if we are doing any new jaggery application, we MUST follow caramel as that is the standard.
-1 for Caramel - below are my reasons 
  • Caramel is not really a framework. It's a template engine that does dynamic engine. It's an overkill for applications (that's not meant for overriding) 
  • A front end controller is required for an application due authentication, custom controller actions, monitoring etc.
  • Caramel enforce carmel objects into the controller jags 

If there are improvements lets do it to Caramel.
-1 reasons for not improving Caramel are -
  • Caramel is all together a different concept. It's not about a front-end controller. It's about a dynamic template engine 
  • Caramel is kind of procedural where you have to evoke it from controllers
  • Caramel can be used in ways the developer wants. It's exactly opposing the idea of a framework. A framework exert certain things over developer. Caramel makes everyone write their own version of MVC (take Store and Publisher for an example.
 
We should not use two libraries in the platform as it will be a maintenance nightmare. So am -1 on developing applications in Absolute. If Caramel is missing functionalities that you desire, please add them to Caramel. 
I am suggesting to drop Caramel support and build a fully functional front-end controller. Caramel was built for something else and it shouldn't be continued because it's not really needed if you really look at it. Why - I am explaining below -

Why do you need a framework - You want to run the X logic on the Y request and display the Z representation to the user. In the world of frameworks - X is a controller, Y is the request, and Z is a display (view). Absolute simply allows you to match a controller to a view based on the user's request. The way you do it is up to you. You can use a conventional base approach as a pattern matching algorithm or a configuration approach.  The underlying framework requirement is just mapping logic to request and rendering representations. 


Regards,
/Nuwan


On Sun, Dec 1, 2013 at 11:45 PM, [hidden email] <[hidden email]> wrote:

Goose.js and Absolute.js training

Goose is a javascript framework for quickly writing APIs. Absolute is a front-end controller framework for jaggery for that can be used to build MVC type applications.

Goose.js - https://github.com/dulichan/goose.js
Absolute.js - https://github.com/dulichan/absolute.js

When
Tue Dec 3, 2013 1pm – 2pm Colombo
Where
3rd Floor Kernel Meeting room (map)
Calendar
[hidden email]
Who
[hidden email] - organizer
Shanmugarajah Sinnathamby
Kasun Dananjaya Delgolla
Gayan Gunawardana
Krishanthi Samarasinghe
Harshan Liyanage
Dilshan Edirisuriya
Niranjan Karunanandham
Dilan Jayakody
WSO2 Training Group

Going?   Yes - Maybe - No    more options »

Invitation from Google Calendar

You are receiving this courtesy email at the account [hidden email] because you are an attendee of this event.

To stop receiving future notifications for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.




--
Thanks & Regards,

Nuwan Bandara
Technical Lead; 
WSO2 Inc. 
lean . enterprise . middleware |  http://wso2.com 
blog : http://nuwanbando.com; email: [hidden email]; phone: <a href="tel:%2B1%20812%20606%207390" value="+18126067390" target="_blank">+1 812 606 7390




--
Chan (Dulitha Wijewantha) 
Software Engineer - Mobile Development
WSO2Mobile 
Lean.Enterprise.Mobileware
  ~Email       [hidden email]
  ~Mobile     <a href="tel:%2B94712112165" value="+94712112165" target="_blank">+94712112165
  ~Website   dulithawijewantha.com
  ~Blog         blog.dulithawijewantha.com
  ~Twitter     @dulitharw



--
Thanks & Regards,

Nuwan Bandara
Technical Lead; 
WSO2 Inc. 
lean . enterprise . middleware |  http://wso2.com 
blog : http://nuwanbando.com; email: [hidden email]; phone: <a href="tel:%2B1%20812%20606%207390" value="+18126067390" target="_blank">+1 812 606 7390




--
Senior Software Engineer

Mobile: <a href="tel:%2B94%2071%2082%20300%2020" value="+94718230020" target="_blank">+94 71 82 300 20




--
Gayan Gunawardana
Software Engineer; WSO2mobile Inc.; http://wso2mobile.com/
Blog: http://gayanj2ee.blogspot.com/



--
Senior Software Engineer

Mobile: <a href="tel:%2B94%2071%2082%20300%2020" value="+94718230020" target="_blank">+94 71 82 300 20




--
Chan (Dulitha Wijewantha) 
Software Engineer - Mobile Development
WSO2Mobile 
Lean.Enterprise.Mobileware
  ~Email       [hidden email]
  ~Mobile     +94712112165
  ~Website   dulithawijewantha.com
  ~Blog         blog.dulithawijewantha.com
  ~Twitter     @dulitharw

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: Invitation: Goose.js and Absolute.js training @ Tue Dec 3, 2013 1pm - 2pm (dulitha@wso2.com)

Dulitha Wijewantha
Sorry guys - I switched from desktop client to web client forgot to remove training group. Now removed.


On Tue, Dec 3, 2013 at 11:21 AM, Dulitha Wijewantha <[hidden email]> wrote:

Hi all,

My comments are inline. Other than that I wrote a sample blogger app that’s there for Caramel in Absolute. It’s found at [1]. My point is - I am willing to talk why Caramel approach is incorrect and why we need a Front-end controller. But folks- you got to be willing to listen. 

[1] - https://github.com/dulichan/absolute-example


PS:- I removed the training group since it’s an internal one. 

Peace~



On Tue, Dec 3, 2013 at 11:09 AM, Venura Kahawala <[hidden email]> wrote:
Hi,

I was not aware that filter concept was removed from jaggery, but we need to have a proper alternative so we can full fill basic needs of a basic web application.

@Nuwan: Could you please give an example on how a controller should be implemented given that my application adheres the caramel standards? If we can come up with a proper way of doing this, it will save a lot of time.  
Regards,
Venura


On Tue, Dec 3, 2013 at 10:55 AM, Gayan Gunawardana <[hidden email]> wrote:
Hi Venura,

We have discussed jaggery filter functionality few months back. You can find more information from [xacml with jaggery] mail thread in [hidden email]. We had the same requirement like how to implement Entitlement filter from jaggery side.

But the final conclusion was there are no filters in jaggery world, what you can do is, route all requests through one controller which will act as your filter 

Ain't this the Front-end controller?
 

I am totally +1 for considering these kind of existing features when implementing a new language.


On Tue, Dec 3, 2013 at 10:29 AM, Venura Kahawala <[hidden email]> wrote:
Hi Nuwan,

I'm new to jaggery world but while I was developing "my-identity" application for IS I found out some limitations in jaggery and Caramel.
What I needed was to implement a filter functionality just as in servlet filter. Purpose of the filter is described. When we have multiple pages and if some page should be restricted for some set of people based on the permissions, groups or some other factor, then we can intercept the request and validate within the filter. This is a basic requirement and it is pretty hard to implement that requirement in jaggery without adding a code segment to each page.

IMO we need to consider these kinds of existing features when implementing a new language. Yes as you mentioned, we need to improve the jaggery and Caramel instead of implementing functionality in separate places, but we should add these functionality since we are moving towards jaggery and caramel.

Regards,
Venura


On Tue, Dec 3, 2013 at 8:06 AM, Nuwan Bandara <[hidden email]> wrote:
Hi Dulitha,

We have had this debate over and over. What am trying to point out here is that we simply CANNOT have another way of writing jaggery apps.

+1 for not having another way to writing jaggery apps. But I don't agree that way to be Caramel. 
 
If we need improvements to Caramel please go ahead and contribute, don't create a new one that serves ur purpose. Caramel was there for sometime and APIM / UES / Store are build on that pattern.

We have used Store and Publisher both and found out that both of them are pretty inconsistent. Maybe Store and Publisher makes Caramel looks complex but I check the blogger sample and found that it's too over complicated. 
 
Front controller is sometimes good and sometime not so good, people will need multiple controller patterns at times. So please dont rely on just one pattern. 

We need multiple controller patterns. But we need a front-end controller. 


In a web app framework there are more things to think about, not just the controllers, most of the elements are well thought and included to caramel. So please take a moment and try to understand the framework and improve it as you need, but dont invent a new thing just for your cause.

The reason why we built absolute is to make writing jaggery apps pragmatic. Caramel is not pragmatic. We can't improve something when both concepts are different like Template engine and Front-end controller.  
 
and please think about the consistency when developing apps/components you cannot and should not just use random technologies here and there.

Random technology? Caramel is random technology. Absolute build on framework concepts found in Rails, Node etc (http://addyosmani.github.io/backbone-fundamentals/#mvc-applied-to-the-web)


Regards,
/Nuwan


On Mon, Dec 2, 2013 at 11:48 AM, Dulitha Wijewantha <[hidden email]> wrote:
Hi Nuwan,
My comments are inline. What I am proposing - is to build a fully functional front-end controller rather than just another template renderer. Let's have a discussion regarding this. I am also refactoring Absolute to provide capability to override how the pattern matching is done. This training is for anyone who is interested in these frameworks- mainly because they are pragmatic. 

On Mon, Dec 2, 2013 at 6:18 PM, Nuwan Bandara <[hidden email]> wrote:
Hi Chan,

We need to review the new security stuff you did for Goose.js (the routing library)

+1 for reviewing security of Goose.js. 
 
and also if we are doing any new jaggery application, we MUST follow caramel as that is the standard.
-1 for Caramel - below are my reasons 
  • Caramel is not really a framework. It's a template engine that does dynamic engine. It's an overkill for applications (that's not meant for overriding) 
  • A front end controller is required for an application due authentication, custom controller actions, monitoring etc.
  • Caramel enforce carmel objects into the controller jags 

If there are improvements lets do it to Caramel.
-1 reasons for not improving Caramel are -
  • Caramel is all together a different concept. It's not about a front-end controller. It's about a dynamic template engine 
  • Caramel is kind of procedural where you have to evoke it from controllers
  • Caramel can be used in ways the developer wants. It's exactly opposing the idea of a framework. A framework exert certain things over developer. Caramel makes everyone write their own version of MVC (take Store and Publisher for an example.
 
We should not use two libraries in the platform as it will be a maintenance nightmare. So am -1 on developing applications in Absolute. If Caramel is missing functionalities that you desire, please add them to Caramel. 
I am suggesting to drop Caramel support and build a fully functional front-end controller. Caramel was built for something else and it shouldn't be continued because it's not really needed if you really look at it. Why - I am explaining below -

Why do you need a framework - You want to run the X logic on the Y request and display the Z representation to the user. In the world of frameworks - X is a controller, Y is the request, and Z is a display (view). Absolute simply allows you to match a controller to a view based on the user's request. The way you do it is up to you. You can use a conventional base approach as a pattern matching algorithm or a configuration approach.  The underlying framework requirement is just mapping logic to request and rendering representations. 


Regards,
/Nuwan


On Sun, Dec 1, 2013 at 11:45 PM, [hidden email] <[hidden email]> wrote:

Goose.js and Absolute.js training

Goose is a javascript framework for quickly writing APIs. Absolute is a front-end controller framework for jaggery for that can be used to build MVC type applications.

Goose.js - https://github.com/dulichan/goose.js
Absolute.js - https://github.com/dulichan/absolute.js

When
Tue Dec 3, 2013 1pm – 2pm Colombo
Where
3rd Floor Kernel Meeting room (map)
Calendar
[hidden email]
Who
[hidden email] - organizer
Shanmugarajah Sinnathamby
Kasun Dananjaya Delgolla
Gayan Gunawardana
Krishanthi Samarasinghe
Harshan Liyanage
Dilshan Edirisuriya
Niranjan Karunanandham
Dilan Jayakody
WSO2 Training Group

Going?   Yes - Maybe - No    more options »

Invitation from Google Calendar

You are receiving this courtesy email at the account [hidden email] because you are an attendee of this event.

To stop receiving future notifications for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.




--
Thanks & Regards,

Nuwan Bandara
Technical Lead; 
WSO2 Inc. 
lean . enterprise . middleware |  http://wso2.com 
blog : http://nuwanbando.com; email: [hidden email]; phone: <a href="tel:%2B1%20812%20606%207390" value="+18126067390" target="_blank">+1 812 606 7390




--
Chan (Dulitha Wijewantha) 
Software Engineer - Mobile Development
WSO2Mobile 
Lean.Enterprise.Mobileware
  ~Email       [hidden email]
  ~Mobile     <a href="tel:%2B94712112165" value="+94712112165" target="_blank">+94712112165
  ~Website   dulithawijewantha.com
  ~Blog         blog.dulithawijewantha.com
  ~Twitter     @dulitharw



--
Thanks & Regards,

Nuwan Bandara
Technical Lead; 
WSO2 Inc. 
lean . enterprise . middleware |  http://wso2.com 
blog : http://nuwanbando.com; email: [hidden email]; phone: <a href="tel:%2B1%20812%20606%207390" value="+18126067390" target="_blank">+1 812 606 7390




--
Senior Software Engineer

Mobile: <a href="tel:%2B94%2071%2082%20300%2020" value="+94718230020" target="_blank">+94 71 82 300 20




--
Gayan Gunawardana
Software Engineer; WSO2mobile Inc.; http://wso2mobile.com/
Blog: http://gayanj2ee.blogspot.com/



--
Senior Software Engineer

Mobile: <a href="tel:%2B94%2071%2082%20300%2020" value="+94718230020" target="_blank">+94 71 82 300 20




--
Chan (Dulitha Wijewantha) 
Software Engineer - Mobile Development
WSO2Mobile 
Lean.Enterprise.Mobileware
  ~Email       [hidden email]
  ~Mobile     <a href="tel:%2B94712112165" value="+94712112165" target="_blank">+94712112165
  ~Website   dulithawijewantha.com
  ~Blog         blog.dulithawijewantha.com
  ~Twitter     @dulitharw



--
Chan (Dulitha Wijewantha) 
Software Engineer - Mobile Development
WSO2Mobile 
Lean.Enterprise.Mobileware
  ~Email       [hidden email]
  ~Mobile     +94712112165
  ~Website   dulithawijewantha.com
  ~Blog         blog.dulithawijewantha.com
  ~Twitter     @dulitharw

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: Invitation: Goose.js and Absolute.js training @ Tue Dec 3, 2013 1pm - 2pm (dulitha@wso2.com)

Nuwan Bandara-2
In reply to this post by Dulitha Wijewantha
Hi 


On Tue, Dec 3, 2013 at 12:51 AM, Dulitha Wijewantha <[hidden email]> wrote:

Hi all,

My comments are inline. Other than that I wrote a sample blogger app that’s there for Caramel in Absolute. It’s found at [1]. My point is - I am willing to talk why Caramel approach is incorrect and why we need a Front-end controller. But folks- you got to be willing to listen. 

Its not about willing to listen, its just we were listening and talking about this for months and you always want to do your own framework, which will not work. How things should work is that if you need improvements in an already existing library / framework you can improve that while taking the good parts of it. 

From how I see it, Caramel has tons of very useful utilities we have written to support all the requirements of a large application (cacheing / i18n / templating / frontend-backend rendering / content negotiation etc etc  ). But what you are keep on complaining is not having a front controller. Am not against having a front controller its perfectly fine to have it, but have it in caramel and improve it so every one can use it. 

Also FYI FE-controller pattern is one of the patterns not THE way of doing things, the fact that you have worked with rails and thats how rails work doesn't justify that all frameworks should look like that. So please take a look at things and try to improve whats already there, Its always easy to write everything from scratch, but when we try to accommodate all the requirements things wont stay simple.

So shall we not waste time talking about it, but rather have a meeting and get whats useful from absolute and have it in Caramel and be done with it. 

@Chan please schedule a meeting with all interested parties, Myself and Ruchira are in EST

Also just FYI Caramel will be the way we will be writing jaggery Apps in WSO2, its like the carbon for java applications / components so anybody is welcome to contribute and improve the framework.

Regards,
/Nuwan
  

[1] - https://github.com/dulichan/absolute-example


PS:- I removed the training group since it’s an internal one. 

Peace~



On Tue, Dec 3, 2013 at 11:09 AM, Venura Kahawala <[hidden email]> wrote:
Hi,

I was not aware that filter concept was removed from jaggery, but we need to have a proper alternative so we can full fill basic needs of a basic web application.

@Nuwan: Could you please give an example on how a controller should be implemented given that my application adheres the caramel standards? If we can come up with a proper way of doing this, it will save a lot of time.  
Regards,
Venura


On Tue, Dec 3, 2013 at 10:55 AM, Gayan Gunawardana <[hidden email]> wrote:
Hi Venura,

We have discussed jaggery filter functionality few months back. You can find more information from [xacml with jaggery] mail thread in [hidden email]. We had the same requirement like how to implement Entitlement filter from jaggery side.

But the final conclusion was there are no filters in jaggery world, what you can do is, route all requests through one controller which will act as your filter 

Ain't this the Front-end controller?
 

I am totally +1 for considering these kind of existing features when implementing a new language.


On Tue, Dec 3, 2013 at 10:29 AM, Venura Kahawala <[hidden email]> wrote:
Hi Nuwan,

I'm new to jaggery world but while I was developing "my-identity" application for IS I found out some limitations in jaggery and Caramel.
What I needed was to implement a filter functionality just as in servlet filter. Purpose of the filter is described. When we have multiple pages and if some page should be restricted for some set of people based on the permissions, groups or some other factor, then we can intercept the request and validate within the filter. This is a basic requirement and it is pretty hard to implement that requirement in jaggery without adding a code segment to each page.

IMO we need to consider these kinds of existing features when implementing a new language. Yes as you mentioned, we need to improve the jaggery and Caramel instead of implementing functionality in separate places, but we should add these functionality since we are moving towards jaggery and caramel.

Regards,
Venura


On Tue, Dec 3, 2013 at 8:06 AM, Nuwan Bandara <[hidden email]> wrote:
Hi Dulitha,

We have had this debate over and over. What am trying to point out here is that we simply CANNOT have another way of writing jaggery apps.

+1 for not having another way to writing jaggery apps. But I don't agree that way to be Caramel. 
 
If we need improvements to Caramel please go ahead and contribute, don't create a new one that serves ur purpose. Caramel was there for sometime and APIM / UES / Store are build on that pattern.

We have used Store and Publisher both and found out that both of them are pretty inconsistent. Maybe Store and Publisher makes Caramel looks complex but I check the blogger sample and found that it's too over complicated. 
 
Front controller is sometimes good and sometime not so good, people will need multiple controller patterns at times. So please dont rely on just one pattern. 

We need multiple controller patterns. But we need a front-end controller. 


In a web app framework there are more things to think about, not just the controllers, most of the elements are well thought and included to caramel. So please take a moment and try to understand the framework and improve it as you need, but dont invent a new thing just for your cause.

The reason why we built absolute is to make writing jaggery apps pragmatic. Caramel is not pragmatic. We can't improve something when both concepts are different like Template engine and Front-end controller.  
 
and please think about the consistency when developing apps/components you cannot and should not just use random technologies here and there.

Random technology? Caramel is random technology. Absolute build on framework concepts found in Rails, Node etc (http://addyosmani.github.io/backbone-fundamentals/#mvc-applied-to-the-web)


Regards,
/Nuwan


On Mon, Dec 2, 2013 at 11:48 AM, Dulitha Wijewantha <[hidden email]> wrote:
Hi Nuwan,
My comments are inline. What I am proposing - is to build a fully functional front-end controller rather than just another template renderer. Let's have a discussion regarding this. I am also refactoring Absolute to provide capability to override how the pattern matching is done. This training is for anyone who is interested in these frameworks- mainly because they are pragmatic. 

On Mon, Dec 2, 2013 at 6:18 PM, Nuwan Bandara <[hidden email]> wrote:
Hi Chan,

We need to review the new security stuff you did for Goose.js (the routing library)

+1 for reviewing security of Goose.js. 
 
and also if we are doing any new jaggery application, we MUST follow caramel as that is the standard.
-1 for Caramel - below are my reasons 
  • Caramel is not really a framework. It's a template engine that does dynamic engine. It's an overkill for applications (that's not meant for overriding) 
  • A front end controller is required for an application due authentication, custom controller actions, monitoring etc.
  • Caramel enforce carmel objects into the controller jags 

If there are improvements lets do it to Caramel.
-1 reasons for not improving Caramel are -
  • Caramel is all together a different concept. It's not about a front-end controller. It's about a dynamic template engine 
  • Caramel is kind of procedural where you have to evoke it from controllers
  • Caramel can be used in ways the developer wants. It's exactly opposing the idea of a framework. A framework exert certain things over developer. Caramel makes everyone write their own version of MVC (take Store and Publisher for an example.
 
We should not use two libraries in the platform as it will be a maintenance nightmare. So am -1 on developing applications in Absolute. If Caramel is missing functionalities that you desire, please add them to Caramel. 
I am suggesting to drop Caramel support and build a fully functional front-end controller. Caramel was built for something else and it shouldn't be continued because it's not really needed if you really look at it. Why - I am explaining below -

Why do you need a framework - You want to run the X logic on the Y request and display the Z representation to the user. In the world of frameworks - X is a controller, Y is the request, and Z is a display (view). Absolute simply allows you to match a controller to a view based on the user's request. The way you do it is up to you. You can use a conventional base approach as a pattern matching algorithm or a configuration approach.  The underlying framework requirement is just mapping logic to request and rendering representations. 


Regards,
/Nuwan


On Sun, Dec 1, 2013 at 11:45 PM, [hidden email] <[hidden email]> wrote:

Goose.js and Absolute.js training

Goose is a javascript framework for quickly writing APIs. Absolute is a front-end controller framework for jaggery for that can be used to build MVC type applications.

Goose.js - https://github.com/dulichan/goose.js
Absolute.js - https://github.com/dulichan/absolute.js

When
Tue Dec 3, 2013 1pm – 2pm Colombo
Where
3rd Floor Kernel Meeting room (map)
Calendar
[hidden email]
Who
[hidden email] - organizer
Shanmugarajah Sinnathamby
Kasun Dananjaya Delgolla
Gayan Gunawardana
Krishanthi Samarasinghe
Harshan Liyanage
Dilshan Edirisuriya
Niranjan Karunanandham
Dilan Jayakody
WSO2 Training Group

Going?   Yes - Maybe - No    more options »

Invitation from Google Calendar

You are receiving this courtesy email at the account [hidden email] because you are an attendee of this event.

To stop receiving future notifications for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.




--
Thanks & Regards,

Nuwan Bandara
Technical Lead; 
WSO2 Inc. 
lean . enterprise . middleware |  http://wso2.com 
blog : http://nuwanbando.com; email: [hidden email]; phone: <a href="tel:%2B1%20812%20606%207390" value="+18126067390" target="_blank">+1 812 606 7390




--
Chan (Dulitha Wijewantha) 
Software Engineer - Mobile Development
WSO2Mobile 
Lean.Enterprise.Mobileware
  ~Email       [hidden email]
  ~Mobile     <a href="tel:%2B94712112165" value="+94712112165" target="_blank">+94712112165
  ~Website   dulithawijewantha.com
  ~Blog         blog.dulithawijewantha.com
  ~Twitter     @dulitharw



--
Thanks & Regards,

Nuwan Bandara
Technical Lead; 
WSO2 Inc. 
lean . enterprise . middleware |  http://wso2.com 
blog : http://nuwanbando.com; email: [hidden email]; phone: <a href="tel:%2B1%20812%20606%207390" value="+18126067390" target="_blank">+1 812 606 7390




--
Senior Software Engineer

Mobile: <a href="tel:%2B94%2071%2082%20300%2020" value="+94718230020" target="_blank">+94 71 82 300 20




--
Gayan Gunawardana
Software Engineer; WSO2mobile Inc.; http://wso2mobile.com/
Blog: http://gayanj2ee.blogspot.com/



--
Senior Software Engineer

Mobile: <a href="tel:%2B94%2071%2082%20300%2020" value="+94718230020" target="_blank">+94 71 82 300 20




--
Chan (Dulitha Wijewantha) 
Software Engineer - Mobile Development
WSO2Mobile 
Lean.Enterprise.Mobileware
  ~Email       [hidden email]
  ~Mobile     <a href="tel:%2B94712112165" value="+94712112165" target="_blank">+94712112165
  ~Website   dulithawijewantha.com
  ~Blog         blog.dulithawijewantha.com
  ~Twitter     @dulitharw



--
Thanks & Regards,

Nuwan Bandara
Technical Lead; 
WSO2 Inc. 
lean . enterprise . middleware |  http://wso2.com 
blog : http://nuwanbando.com; email: [hidden email]; phone: +1 812 606 7390


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: Invitation: Goose.js and Absolute.js training @ Tue Dec 3, 2013 1pm - 2pm (dulitha@wso2.com)

Ruchira Wageesha
Hi All,

As most of the people argued here, caramel doesn't have a front-end controller functionality. Not having front-end controller pattern is neither a limitation in Jaggery nor caramel. Reason was we didn't implement it. That's why we have mentioned so many times to integrate it with goosejs or whatever and improve it. Further, caramel was initiated based on drupals UI block concept and improved to suite our environment/requirements.

caramel might have good points and bad points. What we need to do is keep the good, remove the bad and improve it. When you found some issue with carbon core, will you fix that and improve carbon core or will you introduce something else like carbon core? Then when someone else like you found another limitation in your new replacement, he will write his own. This will be continued like this for ever unless you are the smartest guy who developed it 100% perfectly for each and every requirement that comes even in the future. i.e. There shouldn't be any ticket for an improvement under your new framework.

But that's not the open source culture. If caramel/jaggery has problems, you can take the ownership and contribute. Both of them are Apache projects and no one is there to stop your contribution/commits. You can go ahead and improve wherever needed, that's the whole point of being it open source. It might be a complete re-write as we do with carbon 5. But still it should be CARBON and should have all the features/problems that we had addressed. Otherwise, when someone is using it for a long time, they will come up with older requirements and you will have to re-invent the wheel.

AFAIK, non-of the available frameworks don't directly addresses what we need. That's why we wrote caramel, just to give what we want and keep the rest as any developer wants. That's why either goose/frontend controller or whatever can be integrated to caramel. 

What caramel CORE enforces is, just passe all the data that you want render into caramel.render() method. That's it and you can have your own theming, templating language, goosejs etc. Its because we didn't think locking down your file structure or the whole app in a way that we wanted might not be good for everyone. 

You will probably say we have seen a particular structure which caramel enforces, reason was explained it in the caramel training, but for the people who wasn't there, will summarize here as well. 

caramel consists of caramel core and plugable engines where you can plug whatever engine with you own data to html rendering mechanism. By default caramel ships with handlebars based engine which enforces the above structure, that's what we developed for UES which can be again improved or write a new, better engine without touching the caramel core. Hope you have already seen [1].

Just to highlight why caramel was designed like that, please find the following.
  • Our webapps don't just target the end user, we have to target the developers as well. People should be able to get our store app and customize it as they want and give their clients. But still they should be able to get the updates that we provide with newer releases. If they have just edited our sources, then it will be problematic for migrations. 
  • Customization in the sense, they might be embedding new data like showing related amazon products etc., just re-theming or both.
  • Also, we needed to minimize the developer effort during the development lifecycle. i.e. If someone changed the store tag cloud with a nice HTML 5 canvas based UI, then he shouldn't be going through each and every page where tag cloud is being used, inserting whatever the thirdpart css/js libs that he wants. Further, any new page should be able to include the tag cloud UI with their own tags. They shouldn't need to worry about whether every dependent css/js are satisfied etc. i.e. UI elements should be modularized and should work in self contained manner.
  • Why caramel doesn't exert many things is, just because we don't like to lock down the developers, they should be free to go as they want. We can never think every single thing that a developer will do with a webapp, that's why that flexibility should be there.
  • In real usecases, Z(I am refering Z which described in dulitha's mail) consists of a1(js-1, css-1), a2(js-2, css-2), ....an(js-n, css-n) UI components and you will need to re-use the a1, a2.. in the views Z1, Z2...Zn where there are different pages. If someone updated z1 html and added a new JS file etc., then will I have to go and find where the z1 is used and update everything? Further, we shouldn't be including every dependent js/css in every page even though z1 is not being used in that page.
  • If a SAS app is being built, themes should be customizable by each tenant as they want. App developer shouldn't have to do much extra work to make that available.
  • Should be able to theme based on different roles, users etc.
  • It also has several other things like i18n support, ability to deploy in different contexts without changing any code, exposing all the raw data of a page or partially as a json for client side rendering etc. 
As I mentioned at the begining, caramel contains goods and bads. But all the above might being addressed better with your new framework. Hence you can take the ownership and improve/even completely re-write caramel with a very good architecture and feature set. But at the end, it should go under caramel, which WSO2 recommend and addresses the requirements a Jaggery developer, a WSO2 customer faces.



On Tue, Dec 3, 2013 at 5:42 AM, Nuwan Bandara <[hidden email]> wrote:
Hi 


On Tue, Dec 3, 2013 at 12:51 AM, Dulitha Wijewantha <[hidden email]> wrote:

Hi all,

My comments are inline. Other than that I wrote a sample blogger app that’s there for Caramel in Absolute. It’s found at [1]. My point is - I am willing to talk why Caramel approach is incorrect and why we need a Front-end controller. But folks- you got to be willing to listen. 

Its not about willing to listen, its just we were listening and talking about this for months and you always want to do your own framework, which will not work. How things should work is that if you need improvements in an already existing library / framework you can improve that while taking the good parts of it. 

From how I see it, Caramel has tons of very useful utilities we have written to support all the requirements of a large application (cacheing / i18n / templating / frontend-backend rendering / content negotiation etc etc  ). But what you are keep on complaining is not having a front controller. Am not against having a front controller its perfectly fine to have it, but have it in caramel and improve it so every one can use it. 

Also FYI FE-controller pattern is one of the patterns not THE way of doing things, the fact that you have worked with rails and thats how rails work doesn't justify that all frameworks should look like that. So please take a look at things and try to improve whats already there, Its always easy to write everything from scratch, but when we try to accommodate all the requirements things wont stay simple.

So shall we not waste time talking about it, but rather have a meeting and get whats useful from absolute and have it in Caramel and be done with it. 

@Chan please schedule a meeting with all interested parties, Myself and Ruchira are in EST

Also just FYI Caramel will be the way we will be writing jaggery Apps in WSO2, its like the carbon for java applications / components so anybody is welcome to contribute and improve the framework.

Regards,
/Nuwan
  

[1] - https://github.com/dulichan/absolute-example


PS:- I removed the training group since it’s an internal one. 

Peace~



On Tue, Dec 3, 2013 at 11:09 AM, Venura Kahawala <[hidden email]> wrote:
Hi,

I was not aware that filter concept was removed from jaggery, but we need to have a proper alternative so we can full fill basic needs of a basic web application.

@Nuwan: Could you please give an example on how a controller should be implemented given that my application adheres the caramel standards? If we can come up with a proper way of doing this, it will save a lot of time.  
Regards,
Venura


On Tue, Dec 3, 2013 at 10:55 AM, Gayan Gunawardana <[hidden email]> wrote:
Hi Venura,

We have discussed jaggery filter functionality few months back. You can find more information from [xacml with jaggery] mail thread in [hidden email]. We had the same requirement like how to implement Entitlement filter from jaggery side.

But the final conclusion was there are no filters in jaggery world, what you can do is, route all requests through one controller which will act as your filter 

Ain't this the Front-end controller?
 

I am totally +1 for considering these kind of existing features when implementing a new language.


On Tue, Dec 3, 2013 at 10:29 AM, Venura Kahawala <[hidden email]> wrote:
Hi Nuwan,

I'm new to jaggery world but while I was developing "my-identity" application for IS I found out some limitations in jaggery and Caramel.
What I needed was to implement a filter functionality just as in servlet filter. Purpose of the filter is described. When we have multiple pages and if some page should be restricted for some set of people based on the permissions, groups or some other factor, then we can intercept the request and validate within the filter. This is a basic requirement and it is pretty hard to implement that requirement in jaggery without adding a code segment to each page.

IMO we need to consider these kinds of existing features when implementing a new language. Yes as you mentioned, we need to improve the jaggery and Caramel instead of implementing functionality in separate places, but we should add these functionality since we are moving towards jaggery and caramel.

Regards,
Venura


On Tue, Dec 3, 2013 at 8:06 AM, Nuwan Bandara <[hidden email]> wrote:
Hi Dulitha,

We have had this debate over and over. What am trying to point out here is that we simply CANNOT have another way of writing jaggery apps.

+1 for not having another way to writing jaggery apps. But I don't agree that way to be Caramel. 
 
If we need improvements to Caramel please go ahead and contribute, don't create a new one that serves ur purpose. Caramel was there for sometime and APIM / UES / Store are build on that pattern.

We have used Store and Publisher both and found out that both of them are pretty inconsistent. Maybe Store and Publisher makes Caramel looks complex but I check the blogger sample and found that it's too over complicated. 
 
Front controller is sometimes good and sometime not so good, people will need multiple controller patterns at times. So please dont rely on just one pattern. 

We need multiple controller patterns. But we need a front-end controller. 


In a web app framework there are more things to think about, not just the controllers, most of the elements are well thought and included to caramel. So please take a moment and try to understand the framework and improve it as you need, but dont invent a new thing just for your cause.

The reason why we built absolute is to make writing jaggery apps pragmatic. Caramel is not pragmatic. We can't improve something when both concepts are different like Template engine and Front-end controller.  
 
and please think about the consistency when developing apps/components you cannot and should not just use random technologies here and there.

Random technology? Caramel is random technology. Absolute build on framework concepts found in Rails, Node etc (http://addyosmani.github.io/backbone-fundamentals/#mvc-applied-to-the-web)


Regards,
/Nuwan


On Mon, Dec 2, 2013 at 11:48 AM, Dulitha Wijewantha <[hidden email]> wrote:
Hi Nuwan,
My comments are inline. What I am proposing - is to build a fully functional front-end controller rather than just another template renderer. Let's have a discussion regarding this. I am also refactoring Absolute to provide capability to override how the pattern matching is done. This training is for anyone who is interested in these frameworks- mainly because they are pragmatic. 

On Mon, Dec 2, 2013 at 6:18 PM, Nuwan Bandara <[hidden email]> wrote:
Hi Chan,

We need to review the new security stuff you did for Goose.js (the routing library)

+1 for reviewing security of Goose.js. 
 
and also if we are doing any new jaggery application, we MUST follow caramel as that is the standard.
-1 for Caramel - below are my reasons 
  • Caramel is not really a framework. It's a template engine that does dynamic engine. It's an overkill for applications (that's not meant for overriding) 
  • A front end controller is required for an application due authentication, custom controller actions, monitoring etc.
  • Caramel enforce carmel objects into the controller jags 

If there are improvements lets do it to Caramel.
-1 reasons for not improving Caramel are -
  • Caramel is all together a different concept. It's not about a front-end controller. It's about a dynamic template engine 
  • Caramel is kind of procedural where you have to evoke it from controllers
  • Caramel can be used in ways the developer wants. It's exactly opposing the idea of a framework. A framework exert certain things over developer. Caramel makes everyone write their own version of MVC (take Store and Publisher for an example.
 
We should not use two libraries in the platform as it will be a maintenance nightmare. So am -1 on developing applications in Absolute. If Caramel is missing functionalities that you desire, please add them to Caramel. 
I am suggesting to drop Caramel support and build a fully functional front-end controller. Caramel was built for something else and it shouldn't be continued because it's not really needed if you really look at it. Why - I am explaining below -

Why do you need a framework - You want to run the X logic on the Y request and display the Z representation to the user. In the world of frameworks - X is a controller, Y is the request, and Z is a display (view). Absolute simply allows you to match a controller to a view based on the user's request. The way you do it is up to you. You can use a conventional base approach as a pattern matching algorithm or a configuration approach.  The underlying framework requirement is just mapping logic to request and rendering representations. 


Regards,
/Nuwan


On Sun, Dec 1, 2013 at 11:45 PM, [hidden email] <[hidden email]> wrote:

Goose.js and Absolute.js training

Goose is a javascript framework for quickly writing APIs. Absolute is a front-end controller framework for jaggery for that can be used to build MVC type applications.

Goose.js - https://github.com/dulichan/goose.js
Absolute.js - https://github.com/dulichan/absolute.js

When
Tue Dec 3, 2013 1pm – 2pm Colombo
Where
3rd Floor Kernel Meeting room (map)
Calendar
[hidden email]
Who
[hidden email] - organizer
Shanmugarajah Sinnathamby
Kasun Dananjaya Delgolla
Gayan Gunawardana
Krishanthi Samarasinghe
Harshan Liyanage
Dilshan Edirisuriya
Niranjan Karunanandham
Dilan Jayakody
WSO2 Training Group

Going?   Yes - Maybe - No    more options »

Invitation from Google Calendar

You are receiving this courtesy email at the account [hidden email] because you are an attendee of this event.

To stop receiving future notifications for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.




--
Thanks & Regards,

Nuwan Bandara
Technical Lead; 
WSO2 Inc. 
lean . enterprise . middleware |  http://wso2.com 
blog : http://nuwanbando.com; email: [hidden email]; phone: <a href="tel:%2B1%20812%20606%207390" value="+18126067390" target="_blank">+1 812 606 7390




--
Chan (Dulitha Wijewantha) 
Software Engineer - Mobile Development
WSO2Mobile 
Lean.Enterprise.Mobileware
  ~Email       [hidden email]
  ~Mobile     <a href="tel:%2B94712112165" value="+94712112165" target="_blank">+94712112165
  ~Website   dulithawijewantha.com
  ~Blog         blog.dulithawijewantha.com
  ~Twitter     @dulitharw



--
Thanks & Regards,

Nuwan Bandara
Technical Lead; 
WSO2 Inc. 
lean . enterprise . middleware |  http://wso2.com 
blog : http://nuwanbando.com; email: [hidden email]; phone: <a href="tel:%2B1%20812%20606%207390" value="+18126067390" target="_blank">+1 812 606 7390




--
Senior Software Engineer

Mobile: <a href="tel:%2B94%2071%2082%20300%2020" value="+94718230020" target="_blank">+94 71 82 300 20




--
Gayan Gunawardana
Software Engineer; WSO2mobile Inc.; http://wso2mobile.com/
Blog: http://gayanj2ee.blogspot.com/



--
Senior Software Engineer

Mobile: <a href="tel:%2B94%2071%2082%20300%2020" value="+94718230020" target="_blank">+94 71 82 300 20




--
Chan (Dulitha Wijewantha) 
Software Engineer - Mobile Development
WSO2Mobile 
Lean.Enterprise.Mobileware
  ~Email       [hidden email]
  ~Mobile     <a href="tel:%2B94712112165" value="+94712112165" target="_blank">+94712112165
  ~Website   dulithawijewantha.com
  ~Blog         blog.dulithawijewantha.com
  ~Twitter     @dulitharw



--
Thanks & Regards,

Nuwan Bandara
Technical Lead; 
WSO2 Inc. 
lean . enterprise . middleware |  http://wso2.com 
blog : http://nuwanbando.com; email: [hidden email]; phone: <a href="tel:%2B1%20812%20606%207390" value="+18126067390" target="_blank">+1 812 606 7390




--
Ruchira Wageesha
Associate Technical Lead
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: [hidden email],   blog: ruchirawageesha.blogspot.com,   mobile: +94 77 5493444


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: Invitation: Goose.js and Absolute.js training @ Tue Dec 3, 2013 1pm - 2pm (dulitha@wso2.com)

Madhuka Udantha
In reply to this post by Dulitha Wijewantha
Hi Dulitha,

Ruchira have given descriptive detail about "Caramel", What caramel can do and not. With my experience caramel is not bad on developing and maintaining applications. You can see API manger store and ES store. We will get my point easily. Front end controller is useful but not all the time and all applications and it depending on requirements. Nice to have it caramel but it should be optional as I see. But in now when some one is writing jaggery app and he/she feels Front End Controller (FEC) for application she/he can have it by develop it by him self.(it is not much work) (Better to have some thing inbuilt In, therefore dulitha I also preferred to have FEC and it is able go with caramel)

So you can try to adding those to caramel or integrate those to caramel. 



On Mon, Dec 2, 2013 at 10:18 PM, Dulitha Wijewantha <[hidden email]> wrote:
Hi Nuwan,
My comments are inline. What I am proposing - is to build a fully functional front-end controller rather than just another template renderer. Let's have a discussion regarding this. I am also refactoring Absolute to provide capability to override how the pattern matching is done. This training is for anyone who is interested in these frameworks- mainly because they are pragmatic. 

On Mon, Dec 2, 2013 at 6:18 PM, Nuwan Bandara <[hidden email]> wrote:
Hi Chan,

We need to review the new security stuff you did for Goose.js (the routing library)

+1 for reviewing security of Goose.js. 
 
and also if we are doing any new jaggery application, we MUST follow caramel as that is the standard.
-1 for Caramel - below are my reasons 
  • Caramel is not really a framework. It's a template engine that does dynamic engine. It's an overkill for applications (that's not meant for overriding) 
  • A front end controller is required for an application due authentication, custom controller actions, monitoring etc.
  • Caramel enforce carmel objects into the controller jags 

If there are improvements lets do it to Caramel.
-1 reasons for not improving Caramel are -
  • Caramel is all together a different concept. It's not about a front-end controller. It's about a dynamic template engine 
  • Caramel is kind of procedural where you have to evoke it from controllers
  • Caramel can be used in ways the developer wants. It's exactly opposing the idea of a framework. A framework exert certain things over developer. Caramel makes everyone write their own version of MVC (take Store and Publisher for an example.
 
We should not use two libraries in the platform as it will be a maintenance nightmare. So am -1 on developing applications in Absolute. If Caramel is missing functionalities that you desire, please add them to Caramel. 
I am suggesting to drop Caramel support and build a fully functional front-end controller. Caramel was built for something else and it shouldn't be continued because it's not really needed if you really look at it. Why - I am explaining below -

Why do you need a framework - You want to run the X logic on the Y request and display the Z representation to the user. In the world of frameworks - X is a controller, Y is the request, and Z is a display (view). Absolute simply allows you to match a controller to a view based on the user's request. The way you do it is up to you. You can use a conventional base approach as a pattern matching algorithm or a configuration approach.  The underlying framework requirement is just mapping logic to request and rendering representations. 


Regards,
/Nuwan


On Sun, Dec 1, 2013 at 11:45 PM, [hidden email] <[hidden email]> wrote:

Goose.js and Absolute.js training

Goose is a javascript framework for quickly writing APIs. Absolute is a front-end controller framework for jaggery for that can be used to build MVC type applications.

Goose.js - https://github.com/dulichan/goose.js
Absolute.js - https://github.com/dulichan/absolute.js

When
Tue Dec 3, 2013 1pm – 2pm Colombo
Where
3rd Floor Kernel Meeting room (map)
Calendar
[hidden email]
Who
[hidden email] - organizer
Shanmugarajah Sinnathamby
Kasun Dananjaya Delgolla
Gayan Gunawardana
Krishanthi Samarasinghe
Harshan Liyanage
Dilshan Edirisuriya
Niranjan Karunanandham
Dilan Jayakody
WSO2 Training Group

Going?   Yes - Maybe - No    more options »

Invitation from Google Calendar

You are receiving this courtesy email at the account [hidden email] because you are an attendee of this event.

To stop receiving future notifications for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.




--
Thanks & Regards,

Nuwan Bandara
Technical Lead; 
WSO2 Inc. 
lean . enterprise . middleware |  http://wso2.com 
blog : http://nuwanbando.com; email: [hidden email]; phone: <a href="tel:%2B1%20812%20606%207390" value="+18126067390" target="_blank">+1 812 606 7390




--
Chan (Dulitha Wijewantha) 
Software Engineer - Mobile Development
WSO2Mobile 
Lean.Enterprise.Mobileware
  ~Email       [hidden email]
  ~Mobile     <a href="tel:%2B94712112165" value="+94712112165" target="_blank">+94712112165
  ~Website   dulithawijewantha.com
  ~Blog         blog.dulithawijewantha.com
  ~Twitter     @dulitharw



--
Madhuka Udantha
Senior Software Engineer
Development Technologies
WSO2 Inc. : http://wso2.com 

Mobile: +94774066336
Bloghttp://madhukaudantha.blogspot.com/

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: Invitation: Goose.js and Absolute.js training @ Tue Dec 3, 2013 1pm - 2pm (dulitha@wso2.com)

Ruchira Wageesha

Hi Dilan,

On Wed, Dec 4, 2013 at 1:12 AM, Chathura Dilan <[hidden email]> wrote:
Hi Ruchira,

I think it is good to publish and article about 'Best practices to follow when using Caramel' and the design patterns which we can use with Caramel. Since it is more generic, there is no proper way we can follow how to use it.
Being open for a framework is good; but being too open cause developers to do lot of work. but when it come to a product, we should have to lock down it in someway, our own way using any design patterns we want, may be the front controller or anything. Caramel need to support it.

If we take a product like 'Generic Store' which is best use of Caramel (of course it should be), there are some questions I have to ask.

First thing is we cannot distinguish between what are the things which handle by Caramel and what are not. Still I have no idea overriding an asset is handle by Caramel or not in ES. Even from the Caramel blog http://wso2.github.io/caramel/ I cannot get any idea .Normally developers expect many thing from a framework to handle automatically without writing hundred lines of codes.
caramel address a few, but bit important stuff that we faced during Jaggery based app developments. If you see that it lacks something, then that's where you need to contribute back and improve as I mentioned in my earlier reply.

Because of the work load we had, we didn't have enough time to properly document caramel. But we had provided you a better sample at https://github.com/ruchiraw/wso2-samples-store. If you have ever followed what we have mentioned in the README, then it should have helped you a lot to understand caramel internals. 

There are too many configurations, it's good to use proper conventions (such as naming files) and it would be very helpful for developers and designers.
Without breaking many things in to partials (such as text of a button), it is better to decide what really need to go in to partials.
If caramel was used to write a just a webapp, then things will be totally different. Generic store is a GENERIC store and it is not just a webapp. Generic store has been written in a way that every asset type gets its own sanbox like envirenment to control their parts. That's why we always asked you to use whatever the extension points that have been provided. Also we always got you feedbacks whenever you found any difficulties with its generic nature.

But if someone did't adhere to the extension mechanism and had edited here and there in the store code base, then it's up to him to handle everything that he faces. That's why they will have to do a huge effort when they switch from one store milestone to the other.

Again, as I have mentioned so many times in offline discussions  generic store is not a good place to learn about caramel. That's why we have written above mentioned sample store app and had pointed you.

Regarding your above partial example, there is only one place where the text of a button has separated into a partial. To be precise, it's is the 'Download' or the 'Bookmark' text. Since that is a generic store and that button text needs to be overridden by different asset types, we had to do so. If you had a better suggestion it would be better if you had given us the feedback as we had many discussions.


If you can publish and article on 'Best practices to follow when using Caramel'  to address above it would be very helpful.



-- 
Regards,

Chatura Dilan Perera

(Senior Software Engineer - WSO2 Mobile)
www.dilan.me



--
Ruchira Wageesha
Associate Technical Lead
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: [hidden email],   blog: ruchirawageesha.blogspot.com,   mobile: +94 77 5493444


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: Invitation: Goose.js and Absolute.js training @ Tue Dec 3, 2013 1pm - 2pm (dulitha@wso2.com)

Samisa Abeysinghe-4
In reply to this post by Ruchira Wageesha
Ruchira, would you like to get the below description and blog about it? 

Thanks,
Samisa...


Samisa Abeysinghe

Vice President Training 

WSO2 Inc. 
http://wso2.com



On Tue, Dec 3, 2013 at 9:08 PM, Ruchira Wageesha <[hidden email]> wrote:
Hi All,

As most of the people argued here, caramel doesn't have a front-end controller functionality. Not having front-end controller pattern is neither a limitation in Jaggery nor caramel. Reason was we didn't implement it. That's why we have mentioned so many times to integrate it with goosejs or whatever and improve it. Further, caramel was initiated based on drupals UI block concept and improved to suite our environment/requirements.

caramel might have good points and bad points. What we need to do is keep the good, remove the bad and improve it. When you found some issue with carbon core, will you fix that and improve carbon core or will you introduce something else like carbon core? Then when someone else like you found another limitation in your new replacement, he will write his own. This will be continued like this for ever unless you are the smartest guy who developed it 100% perfectly for each and every requirement that comes even in the future. i.e. There shouldn't be any ticket for an improvement under your new framework.

But that's not the open source culture. If caramel/jaggery has problems, you can take the ownership and contribute. Both of them are Apache projects and no one is there to stop your contribution/commits. You can go ahead and improve wherever needed, that's the whole point of being it open source. It might be a complete re-write as we do with carbon 5. But still it should be CARBON and should have all the features/problems that we had addressed. Otherwise, when someone is using it for a long time, they will come up with older requirements and you will have to re-invent the wheel.

AFAIK, non-of the available frameworks don't directly addresses what we need. That's why we wrote caramel, just to give what we want and keep the rest as any developer wants. That's why either goose/frontend controller or whatever can be integrated to caramel. 

What caramel CORE enforces is, just passe all the data that you want render into caramel.render() method. That's it and you can have your own theming, templating language, goosejs etc. Its because we didn't think locking down your file structure or the whole app in a way that we wanted might not be good for everyone. 

You will probably say we have seen a particular structure which caramel enforces, reason was explained it in the caramel training, but for the people who wasn't there, will summarize here as well. 

caramel consists of caramel core and plugable engines where you can plug whatever engine with you own data to html rendering mechanism. By default caramel ships with handlebars based engine which enforces the above structure, that's what we developed for UES which can be again improved or write a new, better engine without touching the caramel core. Hope you have already seen [1].

Just to highlight why caramel was designed like that, please find the following.
  • Our webapps don't just target the end user, we have to target the developers as well. People should be able to get our store app and customize it as they want and give their clients. But still they should be able to get the updates that we provide with newer releases. If they have just edited our sources, then it will be problematic for migrations. 
  • Customization in the sense, they might be embedding new data like showing related amazon products etc., just re-theming or both.
  • Also, we needed to minimize the developer effort during the development lifecycle. i.e. If someone changed the store tag cloud with a nice HTML 5 canvas based UI, then he shouldn't be going through each and every page where tag cloud is being used, inserting whatever the thirdpart css/js libs that he wants. Further, any new page should be able to include the tag cloud UI with their own tags. They shouldn't need to worry about whether every dependent css/js are satisfied etc. i.e. UI elements should be modularized and should work in self contained manner.
  • Why caramel doesn't exert many things is, just because we don't like to lock down the developers, they should be free to go as they want. We can never think every single thing that a developer will do with a webapp, that's why that flexibility should be there.
  • In real usecases, Z(I am refering Z which described in dulitha's mail) consists of a1(js-1, css-1), a2(js-2, css-2), ....an(js-n, css-n) UI components and you will need to re-use the a1, a2.. in the views Z1, Z2...Zn where there are different pages. If someone updated z1 html and added a new JS file etc., then will I have to go and find where the z1 is used and update everything? Further, we shouldn't be including every dependent js/css in every page even though z1 is not being used in that page.
  • If a SAS app is being built, themes should be customizable by each tenant as they want. App developer shouldn't have to do much extra work to make that available.
  • Should be able to theme based on different roles, users etc.
  • It also has several other things like i18n support, ability to deploy in different contexts without changing any code, exposing all the raw data of a page or partially as a json for client side rendering etc. 
As I mentioned at the begining, caramel contains goods and bads. But all the above might being addressed better with your new framework. Hence you can take the ownership and improve/even completely re-write caramel with a very good architecture and feature set. But at the end, it should go under caramel, which WSO2 recommend and addresses the requirements a Jaggery developer, a WSO2 customer faces.



On Tue, Dec 3, 2013 at 5:42 AM, Nuwan Bandara <[hidden email]> wrote:
Hi 


On Tue, Dec 3, 2013 at 12:51 AM, Dulitha Wijewantha <[hidden email]> wrote:

Hi all,

My comments are inline. Other than that I wrote a sample blogger app that’s there for Caramel in Absolute. It’s found at [1]. My point is - I am willing to talk why Caramel approach is incorrect and why we need a Front-end controller. But folks- you got to be willing to listen. 

Its not about willing to listen, its just we were listening and talking about this for months and you always want to do your own framework, which will not work. How things should work is that if you need improvements in an already existing library / framework you can improve that while taking the good parts of it. 

From how I see it, Caramel has tons of very useful utilities we have written to support all the requirements of a large application (cacheing / i18n / templating / frontend-backend rendering / content negotiation etc etc  ). But what you are keep on complaining is not having a front controller. Am not against having a front controller its perfectly fine to have it, but have it in caramel and improve it so every one can use it. 

Also FYI FE-controller pattern is one of the patterns not THE way of doing things, the fact that you have worked with rails and thats how rails work doesn't justify that all frameworks should look like that. So please take a look at things and try to improve whats already there, Its always easy to write everything from scratch, but when we try to accommodate all the requirements things wont stay simple.

So shall we not waste time talking about it, but rather have a meeting and get whats useful from absolute and have it in Caramel and be done with it. 

@Chan please schedule a meeting with all interested parties, Myself and Ruchira are in EST

Also just FYI Caramel will be the way we will be writing jaggery Apps in WSO2, its like the carbon for java applications / components so anybody is welcome to contribute and improve the framework.

Regards,
/Nuwan
  

[1] - https://github.com/dulichan/absolute-example


PS:- I removed the training group since it’s an internal one. 

Peace~



On Tue, Dec 3, 2013 at 11:09 AM, Venura Kahawala <[hidden email]> wrote:
Hi,

I was not aware that filter concept was removed from jaggery, but we need to have a proper alternative so we can full fill basic needs of a basic web application.

@Nuwan: Could you please give an example on how a controller should be implemented given that my application adheres the caramel standards? If we can come up with a proper way of doing this, it will save a lot of time.  
Regards,
Venura


On Tue, Dec 3, 2013 at 10:55 AM, Gayan Gunawardana <[hidden email]> wrote:
Hi Venura,

We have discussed jaggery filter functionality few months back. You can find more information from [xacml with jaggery] mail thread in [hidden email]. We had the same requirement like how to implement Entitlement filter from jaggery side.

But the final conclusion was there are no filters in jaggery world, what you can do is, route all requests through one controller which will act as your filter 

Ain't this the Front-end controller?
 

I am totally +1 for considering these kind of existing features when implementing a new language.


On Tue, Dec 3, 2013 at 10:29 AM, Venura Kahawala <[hidden email]> wrote:
Hi Nuwan,

I'm new to jaggery world but while I was developing "my-identity" application for IS I found out some limitations in jaggery and Caramel.
What I needed was to implement a filter functionality just as in servlet filter. Purpose of the filter is described. When we have multiple pages and if some page should be restricted for some set of people based on the permissions, groups or some other factor, then we can intercept the request and validate within the filter. This is a basic requirement and it is pretty hard to implement that requirement in jaggery without adding a code segment to each page.

IMO we need to consider these kinds of existing features when implementing a new language. Yes as you mentioned, we need to improve the jaggery and Caramel instead of implementing functionality in separate places, but we should add these functionality since we are moving towards jaggery and caramel.

Regards,
Venura


On Tue, Dec 3, 2013 at 8:06 AM, Nuwan Bandara <[hidden email]> wrote:
Hi Dulitha,

We have had this debate over and over. What am trying to point out here is that we simply CANNOT have another way of writing jaggery apps.

+1 for not having another way to writing jaggery apps. But I don't agree that way to be Caramel. 
 
If we need improvements to Caramel please go ahead and contribute, don't create a new one that serves ur purpose. Caramel was there for sometime and APIM / UES / Store are build on that pattern.

We have used Store and Publisher both and found out that both of them are pretty inconsistent. Maybe Store and Publisher makes Caramel looks complex but I check the blogger sample and found that it's too over complicated. 
 
Front controller is sometimes good and sometime not so good, people will need multiple controller patterns at times. So please dont rely on just one pattern. 

We need multiple controller patterns. But we need a front-end controller. 


In a web app framework there are more things to think about, not just the controllers, most of the elements are well thought and included to caramel. So please take a moment and try to understand the framework and improve it as you need, but dont invent a new thing just for your cause.

The reason why we built absolute is to make writing jaggery apps pragmatic. Caramel is not pragmatic. We can't improve something when both concepts are different like Template engine and Front-end controller.  
 
and please think about the consistency when developing apps/components you cannot and should not just use random technologies here and there.

Random technology? Caramel is random technology. Absolute build on framework concepts found in Rails, Node etc (http://addyosmani.github.io/backbone-fundamentals/#mvc-applied-to-the-web)


Regards,
/Nuwan


On Mon, Dec 2, 2013 at 11:48 AM, Dulitha Wijewantha <[hidden email]> wrote:
Hi Nuwan,
My comments are inline. What I am proposing - is to build a fully functional front-end controller rather than just another template renderer. Let's have a discussion regarding this. I am also refactoring Absolute to provide capability to override how the pattern matching is done. This training is for anyone who is interested in these frameworks- mainly because they are pragmatic. 

On Mon, Dec 2, 2013 at 6:18 PM, Nuwan Bandara <[hidden email]> wrote:
Hi Chan,

We need to review the new security stuff you did for Goose.js (the routing library)

+1 for reviewing security of Goose.js. 
 
and also if we are doing any new jaggery application, we MUST follow caramel as that is the standard.
-1 for Caramel - below are my reasons 
  • Caramel is not really a framework. It's a template engine that does dynamic engine. It's an overkill for applications (that's not meant for overriding) 
  • A front end controller is required for an application due authentication, custom controller actions, monitoring etc.
  • Caramel enforce carmel objects into the controller jags 

If there are improvements lets do it to Caramel.
-1 reasons for not improving Caramel are -
  • Caramel is all together a different concept. It's not about a front-end controller. It's about a dynamic template engine 
  • Caramel is kind of procedural where you have to evoke it from controllers
  • Caramel can be used in ways the developer wants. It's exactly opposing the idea of a framework. A framework exert certain things over developer. Caramel makes everyone write their own version of MVC (take Store and Publisher for an example.
 
We should not use two libraries in the platform as it will be a maintenance nightmare. So am -1 on developing applications in Absolute. If Caramel is missing functionalities that you desire, please add them to Caramel. 
I am suggesting to drop Caramel support and build a fully functional front-end controller. Caramel was built for something else and it shouldn't be continued because it's not really needed if you really look at it. Why - I am explaining below -

Why do you need a framework - You want to run the X logic on the Y request and display the Z representation to the user. In the world of frameworks - X is a controller, Y is the request, and Z is a display (view). Absolute simply allows you to match a controller to a view based on the user's request. The way you do it is up to you. You can use a conventional base approach as a pattern matching algorithm or a configuration approach.  The underlying framework requirement is just mapping logic to request and rendering representations. 


Regards,
/Nuwan


On Sun, Dec 1, 2013 at 11:45 PM, [hidden email] <[hidden email]> wrote:

Goose.js and Absolute.js training

Goose is a javascript framework for quickly writing APIs. Absolute is a front-end controller framework for jaggery for that can be used to build MVC type applications.

Goose.js - https://github.com/dulichan/goose.js
Absolute.js - https://github.com/dulichan/absolute.js

When
Tue Dec 3, 2013 1pm – 2pm Colombo
Where
3rd Floor Kernel Meeting room (map)
Calendar
[hidden email]
Who
[hidden email] - organizer
Shanmugarajah Sinnathamby
Kasun Dananjaya Delgolla
Gayan Gunawardana
Krishanthi Samarasinghe
Harshan Liyanage
Dilshan Edirisuriya
Niranjan Karunanandham
Dilan Jayakody
WSO2 Training Group

Going?   Yes - Maybe - No    more options »

Invitation from Google Calendar

You are receiving this courtesy email at the account [hidden email] because you are an attendee of this event.

To stop receiving future notifications for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.




--
Thanks & Regards,

Nuwan Bandara
Technical Lead; 
WSO2 Inc. 
lean . enterprise . middleware |  http://wso2.com 
blog : http://nuwanbando.com; email: [hidden email]; phone: <a href="tel:%2B1%20812%20606%207390" value="+18126067390" target="_blank">+1 812 606 7390




--
Chan (Dulitha Wijewantha) 
Software Engineer - Mobile Development
WSO2Mobile 
Lean.Enterprise.Mobileware
  ~Email       [hidden email]
  ~Mobile     <a href="tel:%2B94712112165" value="+94712112165" target="_blank">+94712112165
  ~Website   dulithawijewantha.com
  ~Blog         blog.dulithawijewantha.com
  ~Twitter     @dulitharw



--
Thanks & Regards,

Nuwan Bandara
Technical Lead; 
WSO2 Inc. 
lean . enterprise . middleware |  http://wso2.com 
blog : http://nuwanbando.com; email: [hidden email]; phone: <a href="tel:%2B1%20812%20606%207390" value="+18126067390" target="_blank">+1 812 606 7390




--
Senior Software Engineer

Mobile: <a href="tel:%2B94%2071%2082%20300%2020" value="+94718230020" target="_blank">+94 71 82 300 20




--
Gayan Gunawardana
Software Engineer; WSO2mobile Inc.; http://wso2mobile.com/
Blog: http://gayanj2ee.blogspot.com/



--
Senior Software Engineer

Mobile: <a href="tel:%2B94%2071%2082%20300%2020" value="+94718230020" target="_blank">+94 71 82 300 20




--
Chan (Dulitha Wijewantha) 
Software Engineer - Mobile Development
WSO2Mobile 
Lean.Enterprise.Mobileware
  ~Email       [hidden email]
  ~Mobile     <a href="tel:%2B94712112165" value="+94712112165" target="_blank">+94712112165
  ~Website   dulithawijewantha.com
  ~Blog         blog.dulithawijewantha.com
  ~Twitter     @dulitharw



--
Thanks & Regards,

Nuwan Bandara
Technical Lead; 
WSO2 Inc. 
lean . enterprise . middleware |  http://wso2.com 
blog : http://nuwanbando.com; email: [hidden email]; phone: <a href="tel:%2B1%20812%20606%207390" value="+18126067390" target="_blank">+1 812 606 7390




--
Ruchira Wageesha
Associate Technical Lead
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: [hidden email],   blog: ruchirawageesha.blogspot.com,   mobile: <a href="tel:%2B94%2077%205493444" value="+94775493444" target="_blank">+94 77 5493444



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: Invitation: Goose.js and Absolute.js training @ Tue Dec 3, 2013 1pm - 2pm (dulitha@wso2.com)

Ruchira Wageesha
On Fri, Dec 20, 2013 at 1:57 AM, Samisa Abeysinghe <[hidden email]> wrote:
Ruchira, would you like to get the below description and blog about it? 
Yes, I will do asap.

Thanks,
Samisa...


Samisa Abeysinghe

Vice President Training 

WSO2 Inc. 
http://wso2.com



On Tue, Dec 3, 2013 at 9:08 PM, Ruchira Wageesha <[hidden email]> wrote:
Hi All,

As most of the people argued here, caramel doesn't have a front-end controller functionality. Not having front-end controller pattern is neither a limitation in Jaggery nor caramel. Reason was we didn't implement it. That's why we have mentioned so many times to integrate it with goosejs or whatever and improve it. Further, caramel was initiated based on drupals UI block concept and improved to suite our environment/requirements.

caramel might have good points and bad points. What we need to do is keep the good, remove the bad and improve it. When you found some issue with carbon core, will you fix that and improve carbon core or will you introduce something else like carbon core? Then when someone else like you found another limitation in your new replacement, he will write his own. This will be continued like this for ever unless you are the smartest guy who developed it 100% perfectly for each and every requirement that comes even in the future. i.e. There shouldn't be any ticket for an improvement under your new framework.

But that's not the open source culture. If caramel/jaggery has problems, you can take the ownership and contribute. Both of them are Apache projects and no one is there to stop your contribution/commits. You can go ahead and improve wherever needed, that's the whole point of being it open source. It might be a complete re-write as we do with carbon 5. But still it should be CARBON and should have all the features/problems that we had addressed. Otherwise, when someone is using it for a long time, they will come up with older requirements and you will have to re-invent the wheel.

AFAIK, non-of the available frameworks don't directly addresses what we need. That's why we wrote caramel, just to give what we want and keep the rest as any developer wants. That's why either goose/frontend controller or whatever can be integrated to caramel. 

What caramel CORE enforces is, just passe all the data that you want render into caramel.render() method. That's it and you can have your own theming, templating language, goosejs etc. Its because we didn't think locking down your file structure or the whole app in a way that we wanted might not be good for everyone. 

You will probably say we have seen a particular structure which caramel enforces, reason was explained it in the caramel training, but for the people who wasn't there, will summarize here as well. 

caramel consists of caramel core and plugable engines where you can plug whatever engine with you own data to html rendering mechanism. By default caramel ships with handlebars based engine which enforces the above structure, that's what we developed for UES which can be again improved or write a new, better engine without touching the caramel core. Hope you have already seen [1].

Just to highlight why caramel was designed like that, please find the following.
  • Our webapps don't just target the end user, we have to target the developers as well. People should be able to get our store app and customize it as they want and give their clients. But still they should be able to get the updates that we provide with newer releases. If they have just edited our sources, then it will be problematic for migrations. 
  • Customization in the sense, they might be embedding new data like showing related amazon products etc., just re-theming or both.
  • Also, we needed to minimize the developer effort during the development lifecycle. i.e. If someone changed the store tag cloud with a nice HTML 5 canvas based UI, then he shouldn't be going through each and every page where tag cloud is being used, inserting whatever the thirdpart css/js libs that he wants. Further, any new page should be able to include the tag cloud UI with their own tags. They shouldn't need to worry about whether every dependent css/js are satisfied etc. i.e. UI elements should be modularized and should work in self contained manner.
  • Why caramel doesn't exert many things is, just because we don't like to lock down the developers, they should be free to go as they want. We can never think every single thing that a developer will do with a webapp, that's why that flexibility should be there.
  • In real usecases, Z(I am refering Z which described in dulitha's mail) consists of a1(js-1, css-1), a2(js-2, css-2), ....an(js-n, css-n) UI components and you will need to re-use the a1, a2.. in the views Z1, Z2...Zn where there are different pages. If someone updated z1 html and added a new JS file etc., then will I have to go and find where the z1 is used and update everything? Further, we shouldn't be including every dependent js/css in every page even though z1 is not being used in that page.
  • If a SAS app is being built, themes should be customizable by each tenant as they want. App developer shouldn't have to do much extra work to make that available.
  • Should be able to theme based on different roles, users etc.
  • It also has several other things like i18n support, ability to deploy in different contexts without changing any code, exposing all the raw data of a page or partially as a json for client side rendering etc. 
As I mentioned at the begining, caramel contains goods and bads. But all the above might being addressed better with your new framework. Hence you can take the ownership and improve/even completely re-write caramel with a very good architecture and feature set. But at the end, it should go under caramel, which WSO2 recommend and addresses the requirements a Jaggery developer, a WSO2 customer faces.



On Tue, Dec 3, 2013 at 5:42 AM, Nuwan Bandara <[hidden email]> wrote:
Hi 


On Tue, Dec 3, 2013 at 12:51 AM, Dulitha Wijewantha <[hidden email]> wrote:

Hi all,

My comments are inline. Other than that I wrote a sample blogger app that’s there for Caramel in Absolute. It’s found at [1]. My point is - I am willing to talk why Caramel approach is incorrect and why we need a Front-end controller. But folks- you got to be willing to listen. 

Its not about willing to listen, its just we were listening and talking about this for months and you always want to do your own framework, which will not work. How things should work is that if you need improvements in an already existing library / framework you can improve that while taking the good parts of it. 

From how I see it, Caramel has tons of very useful utilities we have written to support all the requirements of a large application (cacheing / i18n / templating / frontend-backend rendering / content negotiation etc etc  ). But what you are keep on complaining is not having a front controller. Am not against having a front controller its perfectly fine to have it, but have it in caramel and improve it so every one can use it. 

Also FYI FE-controller pattern is one of the patterns not THE way of doing things, the fact that you have worked with rails and thats how rails work doesn't justify that all frameworks should look like that. So please take a look at things and try to improve whats already there, Its always easy to write everything from scratch, but when we try to accommodate all the requirements things wont stay simple.

So shall we not waste time talking about it, but rather have a meeting and get whats useful from absolute and have it in Caramel and be done with it. 

@Chan please schedule a meeting with all interested parties, Myself and Ruchira are in EST

Also just FYI Caramel will be the way we will be writing jaggery Apps in WSO2, its like the carbon for java applications / components so anybody is welcome to contribute and improve the framework.

Regards,
/Nuwan
  

[1] - https://github.com/dulichan/absolute-example


PS:- I removed the training group since it’s an internal one. 

Peace~



On Tue, Dec 3, 2013 at 11:09 AM, Venura Kahawala <[hidden email]> wrote:
Hi,

I was not aware that filter concept was removed from jaggery, but we need to have a proper alternative so we can full fill basic needs of a basic web application.

@Nuwan: Could you please give an example on how a controller should be implemented given that my application adheres the caramel standards? If we can come up with a proper way of doing this, it will save a lot of time.  
Regards,
Venura


On Tue, Dec 3, 2013 at 10:55 AM, Gayan Gunawardana <[hidden email]> wrote:
Hi Venura,

We have discussed jaggery filter functionality few months back. You can find more information from [xacml with jaggery] mail thread in [hidden email]. We had the same requirement like how to implement Entitlement filter from jaggery side.

But the final conclusion was there are no filters in jaggery world, what you can do is, route all requests through one controller which will act as your filter 

Ain't this the Front-end controller?
 

I am totally +1 for considering these kind of existing features when implementing a new language.


On Tue, Dec 3, 2013 at 10:29 AM, Venura Kahawala <[hidden email]> wrote:
Hi Nuwan,

I'm new to jaggery world but while I was developing "my-identity" application for IS I found out some limitations in jaggery and Caramel.
What I needed was to implement a filter functionality just as in servlet filter. Purpose of the filter is described. When we have multiple pages and if some page should be restricted for some set of people based on the permissions, groups or some other factor, then we can intercept the request and validate within the filter. This is a basic requirement and it is pretty hard to implement that requirement in jaggery without adding a code segment to each page.

IMO we need to consider these kinds of existing features when implementing a new language. Yes as you mentioned, we need to improve the jaggery and Caramel instead of implementing functionality in separate places, but we should add these functionality since we are moving towards jaggery and caramel.

Regards,
Venura


On Tue, Dec 3, 2013 at 8:06 AM, Nuwan Bandara <[hidden email]> wrote:
Hi Dulitha,

We have had this debate over and over. What am trying to point out here is that we simply CANNOT have another way of writing jaggery apps.

+1 for not having another way to writing jaggery apps. But I don't agree that way to be Caramel. 
 
If we need improvements to Caramel please go ahead and contribute, don't create a new one that serves ur purpose. Caramel was there for sometime and APIM / UES / Store are build on that pattern.

We have used Store and Publisher both and found out that both of them are pretty inconsistent. Maybe Store and Publisher makes Caramel looks complex but I check the blogger sample and found that it's too over complicated. 
 
Front controller is sometimes good and sometime not so good, people will need multiple controller patterns at times. So please dont rely on just one pattern. 

We need multiple controller patterns. But we need a front-end controller. 


In a web app framework there are more things to think about, not just the controllers, most of the elements are well thought and included to caramel. So please take a moment and try to understand the framework and improve it as you need, but dont invent a new thing just for your cause.

The reason why we built absolute is to make writing jaggery apps pragmatic. Caramel is not pragmatic. We can't improve something when both concepts are different like Template engine and Front-end controller.  
 
and please think about the consistency when developing apps/components you cannot and should not just use random technologies here and there.

Random technology? Caramel is random technology. Absolute build on framework concepts found in Rails, Node etc (http://addyosmani.github.io/backbone-fundamentals/#mvc-applied-to-the-web)


Regards,
/Nuwan


On Mon, Dec 2, 2013 at 11:48 AM, Dulitha Wijewantha <[hidden email]> wrote:
Hi Nuwan,
My comments are inline. What I am proposing - is to build a fully functional front-end controller rather than just another template renderer. Let's have a discussion regarding this. I am also refactoring Absolute to provide capability to override how the pattern matching is done. This training is for anyone who is interested in these frameworks- mainly because they are pragmatic. 

On Mon, Dec 2, 2013 at 6:18 PM, Nuwan Bandara <[hidden email]> wrote:
Hi Chan,

We need to review the new security stuff you did for Goose.js (the routing library)

+1 for reviewing security of Goose.js. 
 
and also if we are doing any new jaggery application, we MUST follow caramel as that is the standard.
-1 for Caramel - below are my reasons 
  • Caramel is not really a framework. It's a template engine that does dynamic engine. It's an overkill for applications (that's not meant for overriding) 
  • A front end controller is required for an application due authentication, custom controller actions, monitoring etc.
  • Caramel enforce carmel objects into the controller jags 

If there are improvements lets do it to Caramel.
-1 reasons for not improving Caramel are -
  • Caramel is all together a different concept. It's not about a front-end controller. It's about a dynamic template engine 
  • Caramel is kind of procedural where you have to evoke it from controllers
  • Caramel can be used in ways the developer wants. It's exactly opposing the idea of a framework. A framework exert certain things over developer. Caramel makes everyone write their own version of MVC (take Store and Publisher for an example.
 
We should not use two libraries in the platform as it will be a maintenance nightmare. So am -1 on developing applications in Absolute. If Caramel is missing functionalities that you desire, please add them to Caramel. 
I am suggesting to drop Caramel support and build a fully functional front-end controller. Caramel was built for something else and it shouldn't be continued because it's not really needed if you really look at it. Why - I am explaining below -

Why do you need a framework - You want to run the X logic on the Y request and display the Z representation to the user. In the world of frameworks - X is a controller, Y is the request, and Z is a display (view). Absolute simply allows you to match a controller to a view based on the user's request. The way you do it is up to you. You can use a conventional base approach as a pattern matching algorithm or a configuration approach.  The underlying framework requirement is just mapping logic to request and rendering representations. 


Regards,
/Nuwan


On Sun, Dec 1, 2013 at 11:45 PM, [hidden email] <[hidden email]> wrote:

Goose.js and Absolute.js training

Goose is a javascript framework for quickly writing APIs. Absolute is a front-end controller framework for jaggery for that can be used to build MVC type applications.

Goose.js - https://github.com/dulichan/goose.js
Absolute.js - https://github.com/dulichan/absolute.js

When
Tue Dec 3, 2013 1pm – 2pm Colombo
Where
3rd Floor Kernel Meeting room (map)
Calendar
[hidden email]
Who
[hidden email] - organizer
Shanmugarajah Sinnathamby
Kasun Dananjaya Delgolla
Gayan Gunawardana
Krishanthi Samarasinghe
Harshan Liyanage
Dilshan Edirisuriya
Niranjan Karunanandham
Dilan Jayakody
WSO2 Training Group

Going?   Yes - Maybe - No    more options »

Invitation from Google Calendar

You are receiving this courtesy email at the account [hidden email] because you are an attendee of this event.

To stop receiving future notifications for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.




--
Thanks & Regards,

Nuwan Bandara
Technical Lead; 
WSO2 Inc. 
lean . enterprise . middleware |  http://wso2.com 
blog : http://nuwanbando.com; email: [hidden email]; phone: <a href="tel:%2B1%20812%20606%207390" value="+18126067390" target="_blank">+1 812 606 7390




--
Chan (Dulitha Wijewantha) 
Software Engineer - Mobile Development
WSO2Mobile 
Lean.Enterprise.Mobileware
  ~Email       [hidden email]
  ~Mobile     <a href="tel:%2B94712112165" value="+94712112165" target="_blank">+94712112165
  ~Website   dulithawijewantha.com
  ~Blog         blog.dulithawijewantha.com
  ~Twitter     @dulitharw



--
Thanks & Regards,

Nuwan Bandara
Technical Lead; 
WSO2 Inc. 
lean . enterprise . middleware |  http://wso2.com 
blog : http://nuwanbando.com; email: [hidden email]; phone: <a href="tel:%2B1%20812%20606%207390" value="+18126067390" target="_blank">+1 812 606 7390




--
Senior Software Engineer

Mobile: <a href="tel:%2B94%2071%2082%20300%2020" value="+94718230020" target="_blank">+94 71 82 300 20




--
Gayan Gunawardana
Software Engineer; WSO2mobile Inc.; http://wso2mobile.com/
Blog: http://gayanj2ee.blogspot.com/



--
Senior Software Engineer

Mobile: <a href="tel:%2B94%2071%2082%20300%2020" value="+94718230020" target="_blank">+94 71 82 300 20




--
Chan (Dulitha Wijewantha) 
Software Engineer - Mobile Development
WSO2Mobile 
Lean.Enterprise.Mobileware
  ~Email       [hidden email]
  ~Mobile     <a href="tel:%2B94712112165" value="+94712112165" target="_blank">+94712112165
  ~Website   dulithawijewantha.com
  ~Blog         blog.dulithawijewantha.com
  ~Twitter     @dulitharw



--
Thanks & Regards,

Nuwan Bandara
Technical Lead; 
WSO2 Inc. 
lean . enterprise . middleware |  http://wso2.com 
blog : http://nuwanbando.com; email: [hidden email]; phone: <a href="tel:%2B1%20812%20606%207390" value="+18126067390" target="_blank">+1 812 606 7390




--
Ruchira Wageesha
Associate Technical Lead
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: [hidden email],   blog: ruchirawageesha.blogspot.com,   mobile: <a href="tel:%2B94%2077%205493444" value="+94775493444" target="_blank">+94 77 5493444





--
Ruchira Wageesha
Associate Technical Lead
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: [hidden email],   blog: ruchirawageesha.blogspot.com,   mobile: +94 77 5493444


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: Invitation: Goose.js and Absolute.js training @ Tue Dec 3, 2013 1pm - 2pm (dulitha@wso2.com)

Samisa Abeysinghe-4
Please send me the link once you do. 

Thanks,
Samisa...


Samisa Abeysinghe

Vice President Training 

WSO2 Inc. 
http://wso2.com



On Fri, Dec 20, 2013 at 12:44 PM, Ruchira Wageesha <[hidden email]> wrote:
On Fri, Dec 20, 2013 at 1:57 AM, Samisa Abeysinghe <[hidden email]> wrote:
Ruchira, would you like to get the below description and blog about it? 
Yes, I will do asap.

Thanks,
Samisa...


Samisa Abeysinghe

Vice President Training 

WSO2 Inc. 
http://wso2.com



On Tue, Dec 3, 2013 at 9:08 PM, Ruchira Wageesha <[hidden email]> wrote:
Hi All,

As most of the people argued here, caramel doesn't have a front-end controller functionality. Not having front-end controller pattern is neither a limitation in Jaggery nor caramel. Reason was we didn't implement it. That's why we have mentioned so many times to integrate it with goosejs or whatever and improve it. Further, caramel was initiated based on drupals UI block concept and improved to suite our environment/requirements.

caramel might have good points and bad points. What we need to do is keep the good, remove the bad and improve it. When you found some issue with carbon core, will you fix that and improve carbon core or will you introduce something else like carbon core? Then when someone else like you found another limitation in your new replacement, he will write his own. This will be continued like this for ever unless you are the smartest guy who developed it 100% perfectly for each and every requirement that comes even in the future. i.e. There shouldn't be any ticket for an improvement under your new framework.

But that's not the open source culture. If caramel/jaggery has problems, you can take the ownership and contribute. Both of them are Apache projects and no one is there to stop your contribution/commits. You can go ahead and improve wherever needed, that's the whole point of being it open source. It might be a complete re-write as we do with carbon 5. But still it should be CARBON and should have all the features/problems that we had addressed. Otherwise, when someone is using it for a long time, they will come up with older requirements and you will have to re-invent the wheel.

AFAIK, non-of the available frameworks don't directly addresses what we need. That's why we wrote caramel, just to give what we want and keep the rest as any developer wants. That's why either goose/frontend controller or whatever can be integrated to caramel. 

What caramel CORE enforces is, just passe all the data that you want render into caramel.render() method. That's it and you can have your own theming, templating language, goosejs etc. Its because we didn't think locking down your file structure or the whole app in a way that we wanted might not be good for everyone. 

You will probably say we have seen a particular structure which caramel enforces, reason was explained it in the caramel training, but for the people who wasn't there, will summarize here as well. 

caramel consists of caramel core and plugable engines where you can plug whatever engine with you own data to html rendering mechanism. By default caramel ships with handlebars based engine which enforces the above structure, that's what we developed for UES which can be again improved or write a new, better engine without touching the caramel core. Hope you have already seen [1].

Just to highlight why caramel was designed like that, please find the following.
  • Our webapps don't just target the end user, we have to target the developers as well. People should be able to get our store app and customize it as they want and give their clients. But still they should be able to get the updates that we provide with newer releases. If they have just edited our sources, then it will be problematic for migrations. 
  • Customization in the sense, they might be embedding new data like showing related amazon products etc., just re-theming or both.
  • Also, we needed to minimize the developer effort during the development lifecycle. i.e. If someone changed the store tag cloud with a nice HTML 5 canvas based UI, then he shouldn't be going through each and every page where tag cloud is being used, inserting whatever the thirdpart css/js libs that he wants. Further, any new page should be able to include the tag cloud UI with their own tags. They shouldn't need to worry about whether every dependent css/js are satisfied etc. i.e. UI elements should be modularized and should work in self contained manner.
  • Why caramel doesn't exert many things is, just because we don't like to lock down the developers, they should be free to go as they want. We can never think every single thing that a developer will do with a webapp, that's why that flexibility should be there.
  • In real usecases, Z(I am refering Z which described in dulitha's mail) consists of a1(js-1, css-1), a2(js-2, css-2), ....an(js-n, css-n) UI components and you will need to re-use the a1, a2.. in the views Z1, Z2...Zn where there are different pages. If someone updated z1 html and added a new JS file etc., then will I have to go and find where the z1 is used and update everything? Further, we shouldn't be including every dependent js/css in every page even though z1 is not being used in that page.
  • If a SAS app is being built, themes should be customizable by each tenant as they want. App developer shouldn't have to do much extra work to make that available.
  • Should be able to theme based on different roles, users etc.
  • It also has several other things like i18n support, ability to deploy in different contexts without changing any code, exposing all the raw data of a page or partially as a json for client side rendering etc. 
As I mentioned at the begining, caramel contains goods and bads. But all the above might being addressed better with your new framework. Hence you can take the ownership and improve/even completely re-write caramel with a very good architecture and feature set. But at the end, it should go under caramel, which WSO2 recommend and addresses the requirements a Jaggery developer, a WSO2 customer faces.



On Tue, Dec 3, 2013 at 5:42 AM, Nuwan Bandara <[hidden email]> wrote:
Hi 


On Tue, Dec 3, 2013 at 12:51 AM, Dulitha Wijewantha <[hidden email]> wrote:

Hi all,

My comments are inline. Other than that I wrote a sample blogger app that’s there for Caramel in Absolute. It’s found at [1]. My point is - I am willing to talk why Caramel approach is incorrect and why we need a Front-end controller. But folks- you got to be willing to listen. 

Its not about willing to listen, its just we were listening and talking about this for months and you always want to do your own framework, which will not work. How things should work is that if you need improvements in an already existing library / framework you can improve that while taking the good parts of it. 

From how I see it, Caramel has tons of very useful utilities we have written to support all the requirements of a large application (cacheing / i18n / templating / frontend-backend rendering / content negotiation etc etc  ). But what you are keep on complaining is not having a front controller. Am not against having a front controller its perfectly fine to have it, but have it in caramel and improve it so every one can use it. 

Also FYI FE-controller pattern is one of the patterns not THE way of doing things, the fact that you have worked with rails and thats how rails work doesn't justify that all frameworks should look like that. So please take a look at things and try to improve whats already there, Its always easy to write everything from scratch, but when we try to accommodate all the requirements things wont stay simple.

So shall we not waste time talking about it, but rather have a meeting and get whats useful from absolute and have it in Caramel and be done with it. 

@Chan please schedule a meeting with all interested parties, Myself and Ruchira are in EST

Also just FYI Caramel will be the way we will be writing jaggery Apps in WSO2, its like the carbon for java applications / components so anybody is welcome to contribute and improve the framework.

Regards,
/Nuwan
  

[1] - https://github.com/dulichan/absolute-example


PS:- I removed the training group since it’s an internal one. 

Peace~



On Tue, Dec 3, 2013 at 11:09 AM, Venura Kahawala <[hidden email]> wrote:
Hi,

I was not aware that filter concept was removed from jaggery, but we need to have a proper alternative so we can full fill basic needs of a basic web application.

@Nuwan: Could you please give an example on how a controller should be implemented given that my application adheres the caramel standards? If we can come up with a proper way of doing this, it will save a lot of time.  
Regards,
Venura


On Tue, Dec 3, 2013 at 10:55 AM, Gayan Gunawardana <[hidden email]> wrote:
Hi Venura,

We have discussed jaggery filter functionality few months back. You can find more information from [xacml with jaggery] mail thread in [hidden email]. We had the same requirement like how to implement Entitlement filter from jaggery side.

But the final conclusion was there are no filters in jaggery world, what you can do is, route all requests through one controller which will act as your filter 

Ain't this the Front-end controller?
 

I am totally +1 for considering these kind of existing features when implementing a new language.


On Tue, Dec 3, 2013 at 10:29 AM, Venura Kahawala <[hidden email]> wrote:
Hi Nuwan,

I'm new to jaggery world but while I was developing "my-identity" application for IS I found out some limitations in jaggery and Caramel.
What I needed was to implement a filter functionality just as in servlet filter. Purpose of the filter is described. When we have multiple pages and if some page should be restricted for some set of people based on the permissions, groups or some other factor, then we can intercept the request and validate within the filter. This is a basic requirement and it is pretty hard to implement that requirement in jaggery without adding a code segment to each page.

IMO we need to consider these kinds of existing features when implementing a new language. Yes as you mentioned, we need to improve the jaggery and Caramel instead of implementing functionality in separate places, but we should add these functionality since we are moving towards jaggery and caramel.

Regards,
Venura


On Tue, Dec 3, 2013 at 8:06 AM, Nuwan Bandara <[hidden email]> wrote:
Hi Dulitha,

We have had this debate over and over. What am trying to point out here is that we simply CANNOT have another way of writing jaggery apps.

+1 for not having another way to writing jaggery apps. But I don't agree that way to be Caramel. 
 
If we need improvements to Caramel please go ahead and contribute, don't create a new one that serves ur purpose. Caramel was there for sometime and APIM / UES / Store are build on that pattern.

We have used Store and Publisher both and found out that both of them are pretty inconsistent. Maybe Store and Publisher makes Caramel looks complex but I check the blogger sample and found that it's too over complicated. 
 
Front controller is sometimes good and sometime not so good, people will need multiple controller patterns at times. So please dont rely on just one pattern. 

We need multiple controller patterns. But we need a front-end controller. 


In a web app framework there are more things to think about, not just the controllers, most of the elements are well thought and included to caramel. So please take a moment and try to understand the framework and improve it as you need, but dont invent a new thing just for your cause.

The reason why we built absolute is to make writing jaggery apps pragmatic. Caramel is not pragmatic. We can't improve something when both concepts are different like Template engine and Front-end controller.  
 
and please think about the consistency when developing apps/components you cannot and should not just use random technologies here and there.

Random technology? Caramel is random technology. Absolute build on framework concepts found in Rails, Node etc (http://addyosmani.github.io/backbone-fundamentals/#mvc-applied-to-the-web)


Regards,
/Nuwan


On Mon, Dec 2, 2013 at 11:48 AM, Dulitha Wijewantha <[hidden email]> wrote:
Hi Nuwan,
My comments are inline. What I am proposing - is to build a fully functional front-end controller rather than just another template renderer. Let's have a discussion regarding this. I am also refactoring Absolute to provide capability to override how the pattern matching is done. This training is for anyone who is interested in these frameworks- mainly because they are pragmatic. 

On Mon, Dec 2, 2013 at 6:18 PM, Nuwan Bandara <[hidden email]> wrote:
Hi Chan,

We need to review the new security stuff you did for Goose.js (the routing library)

+1 for reviewing security of Goose.js. 
 
and also if we are doing any new jaggery application, we MUST follow caramel as that is the standard.
-1 for Caramel - below are my reasons 
  • Caramel is not really a framework. It's a template engine that does dynamic engine. It's an overkill for applications (that's not meant for overriding) 
  • A front end controller is required for an application due authentication, custom controller actions, monitoring etc.
  • Caramel enforce carmel objects into the controller jags 

If there are improvements lets do it to Caramel.
-1 reasons for not improving Caramel are -
  • Caramel is all together a different concept. It's not about a front-end controller. It's about a dynamic template engine 
  • Caramel is kind of procedural where you have to evoke it from controllers
  • Caramel can be used in ways the developer wants. It's exactly opposing the idea of a framework. A framework exert certain things over developer. Caramel makes everyone write their own version of MVC (take Store and Publisher for an example.
 
We should not use two libraries in the platform as it will be a maintenance nightmare. So am -1 on developing applications in Absolute. If Caramel is missing functionalities that you desire, please add them to Caramel. 
I am suggesting to drop Caramel support and build a fully functional front-end controller. Caramel was built for something else and it shouldn't be continued because it's not really needed if you really look at it. Why - I am explaining below -

Why do you need a framework - You want to run the X logic on the Y request and display the Z representation to the user. In the world of frameworks - X is a controller, Y is the request, and Z is a display (view). Absolute simply allows you to match a controller to a view based on the user's request. The way you do it is up to you. You can use a conventional base approach as a pattern matching algorithm or a configuration approach.  The underlying framework requirement is just mapping logic to request and rendering representations. 


Regards,
/Nuwan


On Sun, Dec 1, 2013 at 11:45 PM, [hidden email] <[hidden email]> wrote:

Goose.js and Absolute.js training

Goose is a javascript framework for quickly writing APIs. Absolute is a front-end controller framework for jaggery for that can be used to build MVC type applications.

Goose.js - https://github.com/dulichan/goose.js
Absolute.js - https://github.com/dulichan/absolute.js

When
Tue Dec 3, 2013 1pm – 2pm Colombo
Where
3rd Floor Kernel Meeting room (map)
Calendar
[hidden email]
Who
[hidden email] - organizer
Shanmugarajah Sinnathamby
Kasun Dananjaya Delgolla
Gayan Gunawardana
Krishanthi Samarasinghe
Harshan Liyanage
Dilshan Edirisuriya
Niranjan Karunanandham
Dilan Jayakody
WSO2 Training Group

Going?   Yes - Maybe - No    more options »

Invitation from Google Calendar

You are receiving this courtesy email at the account [hidden email] because you are an attendee of this event.

To stop receiving future notifications for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.




--
Thanks & Regards,

Nuwan Bandara
Technical Lead; 
WSO2 Inc. 
lean . enterprise . middleware |  http://wso2.com 
blog : http://nuwanbando.com; email: [hidden email]; phone: <a href="tel:%2B1%20812%20606%207390" value="+18126067390" target="_blank">+1 812 606 7390




--
Chan (Dulitha Wijewantha) 
Software Engineer - Mobile Development
WSO2Mobile 
Lean.Enterprise.Mobileware
  ~Email       [hidden email]
  ~Mobile     <a href="tel:%2B94712112165" value="+94712112165" target="_blank">+94712112165
  ~Website   dulithawijewantha.com
  ~Blog         blog.dulithawijewantha.com
  ~Twitter     @dulitharw



--
Thanks & Regards,

Nuwan Bandara
Technical Lead; 
WSO2 Inc. 
lean . enterprise . middleware |  http://wso2.com 
blog : http://nuwanbando.com; email: [hidden email]; phone: <a href="tel:%2B1%20812%20606%207390" value="+18126067390" target="_blank">+1 812 606 7390




--
Senior Software Engineer

Mobile: <a href="tel:%2B94%2071%2082%20300%2020" value="+94718230020" target="_blank">+94 71 82 300 20




--
Gayan Gunawardana
Software Engineer; WSO2mobile Inc.; http://wso2mobile.com/
Blog: http://gayanj2ee.blogspot.com/



--
Senior Software Engineer

Mobile: <a href="tel:%2B94%2071%2082%20300%2020" value="+94718230020" target="_blank">+94 71 82 300 20




--
Chan (Dulitha Wijewantha) 
Software Engineer - Mobile Development
WSO2Mobile 
Lean.Enterprise.Mobileware
  ~Email       [hidden email]
  ~Mobile     <a href="tel:%2B94712112165" value="+94712112165" target="_blank">+94712112165
  ~Website   dulithawijewantha.com
  ~Blog         blog.dulithawijewantha.com
  ~Twitter     @dulitharw



--
Thanks & Regards,

Nuwan Bandara
Technical Lead; 
WSO2 Inc. 
lean . enterprise . middleware |  http://wso2.com 
blog : http://nuwanbando.com; email: [hidden email]; phone: <a href="tel:%2B1%20812%20606%207390" value="+18126067390" target="_blank">+1 812 606 7390




--
Ruchira Wageesha
Associate Technical Lead
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: [hidden email],   blog: ruchirawageesha.blogspot.com,   mobile: <a href="tel:%2B94%2077%205493444" value="+94775493444" target="_blank">+94 77 5493444





--
Ruchira Wageesha
Associate Technical Lead
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: [hidden email],   blog: ruchirawageesha.blogspot.com,   mobile: <a href="tel:%2B94%2077%205493444" value="+94775493444" target="_blank">+94 77 5493444



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: Invitation: Goose.js and Absolute.js training @ Tue Dec 3, 2013 1pm - 2pm (dulitha@wso2.com)

Samisa Abeysinghe-4
Can we please write this blog? 

Thanks,
Samisa...


Samisa Abeysinghe

Vice President Developer Evangelism

WSO2 Inc. 
http://wso2.com



On Mon, Dec 23, 2013 at 11:54 AM, Samisa Abeysinghe <[hidden email]> wrote:
Please send me the link once you do. 

Thanks,
Samisa...


Samisa Abeysinghe

Vice President Training 

WSO2 Inc. 
http://wso2.com



On Fri, Dec 20, 2013 at 12:44 PM, Ruchira Wageesha <[hidden email]> wrote:
On Fri, Dec 20, 2013 at 1:57 AM, Samisa Abeysinghe <[hidden email]> wrote:
Ruchira, would you like to get the below description and blog about it? 
Yes, I will do asap.

Thanks,
Samisa...


Samisa Abeysinghe

Vice President Training 

WSO2 Inc. 
http://wso2.com



On Tue, Dec 3, 2013 at 9:08 PM, Ruchira Wageesha <[hidden email]> wrote:
Hi All,

As most of the people argued here, caramel doesn't have a front-end controller functionality. Not having front-end controller pattern is neither a limitation in Jaggery nor caramel. Reason was we didn't implement it. That's why we have mentioned so many times to integrate it with goosejs or whatever and improve it. Further, caramel was initiated based on drupals UI block concept and improved to suite our environment/requirements.

caramel might have good points and bad points. What we need to do is keep the good, remove the bad and improve it. When you found some issue with carbon core, will you fix that and improve carbon core or will you introduce something else like carbon core? Then when someone else like you found another limitation in your new replacement, he will write his own. This will be continued like this for ever unless you are the smartest guy who developed it 100% perfectly for each and every requirement that comes even in the future. i.e. There shouldn't be any ticket for an improvement under your new framework.

But that's not the open source culture. If caramel/jaggery has problems, you can take the ownership and contribute. Both of them are Apache projects and no one is there to stop your contribution/commits. You can go ahead and improve wherever needed, that's the whole point of being it open source. It might be a complete re-write as we do with carbon 5. But still it should be CARBON and should have all the features/problems that we had addressed. Otherwise, when someone is using it for a long time, they will come up with older requirements and you will have to re-invent the wheel.

AFAIK, non-of the available frameworks don't directly addresses what we need. That's why we wrote caramel, just to give what we want and keep the rest as any developer wants. That's why either goose/frontend controller or whatever can be integrated to caramel. 

What caramel CORE enforces is, just passe all the data that you want render into caramel.render() method. That's it and you can have your own theming, templating language, goosejs etc. Its because we didn't think locking down your file structure or the whole app in a way that we wanted might not be good for everyone. 

You will probably say we have seen a particular structure which caramel enforces, reason was explained it in the caramel training, but for the people who wasn't there, will summarize here as well. 

caramel consists of caramel core and plugable engines where you can plug whatever engine with you own data to html rendering mechanism. By default caramel ships with handlebars based engine which enforces the above structure, that's what we developed for UES which can be again improved or write a new, better engine without touching the caramel core. Hope you have already seen [1].

Just to highlight why caramel was designed like that, please find the following.
  • Our webapps don't just target the end user, we have to target the developers as well. People should be able to get our store app and customize it as they want and give their clients. But still they should be able to get the updates that we provide with newer releases. If they have just edited our sources, then it will be problematic for migrations. 
  • Customization in the sense, they might be embedding new data like showing related amazon products etc., just re-theming or both.
  • Also, we needed to minimize the developer effort during the development lifecycle. i.e. If someone changed the store tag cloud with a nice HTML 5 canvas based UI, then he shouldn't be going through each and every page where tag cloud is being used, inserting whatever the thirdpart css/js libs that he wants. Further, any new page should be able to include the tag cloud UI with their own tags. They shouldn't need to worry about whether every dependent css/js are satisfied etc. i.e. UI elements should be modularized and should work in self contained manner.
  • Why caramel doesn't exert many things is, just because we don't like to lock down the developers, they should be free to go as they want. We can never think every single thing that a developer will do with a webapp, that's why that flexibility should be there.
  • In real usecases, Z(I am refering Z which described in dulitha's mail) consists of a1(js-1, css-1), a2(js-2, css-2), ....an(js-n, css-n) UI components and you will need to re-use the a1, a2.. in the views Z1, Z2...Zn where there are different pages. If someone updated z1 html and added a new JS file etc., then will I have to go and find where the z1 is used and update everything? Further, we shouldn't be including every dependent js/css in every page even though z1 is not being used in that page.
  • If a SAS app is being built, themes should be customizable by each tenant as they want. App developer shouldn't have to do much extra work to make that available.
  • Should be able to theme based on different roles, users etc.
  • It also has several other things like i18n support, ability to deploy in different contexts without changing any code, exposing all the raw data of a page or partially as a json for client side rendering etc. 
As I mentioned at the begining, caramel contains goods and bads. But all the above might being addressed better with your new framework. Hence you can take the ownership and improve/even completely re-write caramel with a very good architecture and feature set. But at the end, it should go under caramel, which WSO2 recommend and addresses the requirements a Jaggery developer, a WSO2 customer faces.



On Tue, Dec 3, 2013 at 5:42 AM, Nuwan Bandara <[hidden email]> wrote:
Hi 


On Tue, Dec 3, 2013 at 12:51 AM, Dulitha Wijewantha <[hidden email]> wrote:

Hi all,

My comments are inline. Other than that I wrote a sample blogger app that’s there for Caramel in Absolute. It’s found at [1]. My point is - I am willing to talk why Caramel approach is incorrect and why we need a Front-end controller. But folks- you got to be willing to listen. 

Its not about willing to listen, its just we were listening and talking about this for months and you always want to do your own framework, which will not work. How things should work is that if you need improvements in an already existing library / framework you can improve that while taking the good parts of it. 

From how I see it, Caramel has tons of very useful utilities we have written to support all the requirements of a large application (cacheing / i18n / templating / frontend-backend rendering / content negotiation etc etc  ). But what you are keep on complaining is not having a front controller. Am not against having a front controller its perfectly fine to have it, but have it in caramel and improve it so every one can use it. 

Also FYI FE-controller pattern is one of the patterns not THE way of doing things, the fact that you have worked with rails and thats how rails work doesn't justify that all frameworks should look like that. So please take a look at things and try to improve whats already there, Its always easy to write everything from scratch, but when we try to accommodate all the requirements things wont stay simple.

So shall we not waste time talking about it, but rather have a meeting and get whats useful from absolute and have it in Caramel and be done with it. 

@Chan please schedule a meeting with all interested parties, Myself and Ruchira are in EST

Also just FYI Caramel will be the way we will be writing jaggery Apps in WSO2, its like the carbon for java applications / components so anybody is welcome to contribute and improve the framework.

Regards,
/Nuwan
  

[1] - https://github.com/dulichan/absolute-example


PS:- I removed the training group since it’s an internal one. 

Peace~



On Tue, Dec 3, 2013 at 11:09 AM, Venura Kahawala <[hidden email]> wrote:
Hi,

I was not aware that filter concept was removed from jaggery, but we need to have a proper alternative so we can full fill basic needs of a basic web application.

@Nuwan: Could you please give an example on how a controller should be implemented given that my application adheres the caramel standards? If we can come up with a proper way of doing this, it will save a lot of time.  
Regards,
Venura


On Tue, Dec 3, 2013 at 10:55 AM, Gayan Gunawardana <[hidden email]> wrote:
Hi Venura,

We have discussed jaggery filter functionality few months back. You can find more information from [xacml with jaggery] mail thread in [hidden email]. We had the same requirement like how to implement Entitlement filter from jaggery side.

But the final conclusion was there are no filters in jaggery world, what you can do is, route all requests through one controller which will act as your filter 

Ain't this the Front-end controller?
 

I am totally +1 for considering these kind of existing features when implementing a new language.


On Tue, Dec 3, 2013 at 10:29 AM, Venura Kahawala <[hidden email]> wrote:
Hi Nuwan,

I'm new to jaggery world but while I was developing "my-identity" application for IS I found out some limitations in jaggery and Caramel.
What I needed was to implement a filter functionality just as in servlet filter. Purpose of the filter is described. When we have multiple pages and if some page should be restricted for some set of people based on the permissions, groups or some other factor, then we can intercept the request and validate within the filter. This is a basic requirement and it is pretty hard to implement that requirement in jaggery without adding a code segment to each page.

IMO we need to consider these kinds of existing features when implementing a new language. Yes as you mentioned, we need to improve the jaggery and Caramel instead of implementing functionality in separate places, but we should add these functionality since we are moving towards jaggery and caramel.

Regards,
Venura


On Tue, Dec 3, 2013 at 8:06 AM, Nuwan Bandara <[hidden email]> wrote:
Hi Dulitha,

We have had this debate over and over. What am trying to point out here is that we simply CANNOT have another way of writing jaggery apps.

+1 for not having another way to writing jaggery apps. But I don't agree that way to be Caramel. 
 
If we need improvements to Caramel please go ahead and contribute, don't create a new one that serves ur purpose. Caramel was there for sometime and APIM / UES / Store are build on that pattern.

We have used Store and Publisher both and found out that both of them are pretty inconsistent. Maybe Store and Publisher makes Caramel looks complex but I check the blogger sample and found that it's too over complicated. 
 
Front controller is sometimes good and sometime not so good, people will need multiple controller patterns at times. So please dont rely on just one pattern. 

We need multiple controller patterns. But we need a front-end controller. 


In a web app framework there are more things to think about, not just the controllers, most of the elements are well thought and included to caramel. So please take a moment and try to understand the framework and improve it as you need, but dont invent a new thing just for your cause.

The reason why we built absolute is to make writing jaggery apps pragmatic. Caramel is not pragmatic. We can't improve something when both concepts are different like Template engine and Front-end controller.  
 
and please think about the consistency when developing apps/components you cannot and should not just use random technologies here and there.

Random technology? Caramel is random technology. Absolute build on framework concepts found in Rails, Node etc (http://addyosmani.github.io/backbone-fundamentals/#mvc-applied-to-the-web)


Regards,
/Nuwan


On Mon, Dec 2, 2013 at 11:48 AM, Dulitha Wijewantha <[hidden email]> wrote:
Hi Nuwan,
My comments are inline. What I am proposing - is to build a fully functional front-end controller rather than just another template renderer. Let's have a discussion regarding this. I am also refactoring Absolute to provide capability to override how the pattern matching is done. This training is for anyone who is interested in these frameworks- mainly because they are pragmatic. 

On Mon, Dec 2, 2013 at 6:18 PM, Nuwan Bandara <[hidden email]> wrote:
Hi Chan,

We need to review the new security stuff you did for Goose.js (the routing library)

+1 for reviewing security of Goose.js. 
 
and also if we are doing any new jaggery application, we MUST follow caramel as that is the standard.
-1 for Caramel - below are my reasons 
  • Caramel is not really a framework. It's a template engine that does dynamic engine. It's an overkill for applications (that's not meant for overriding) 
  • A front end controller is required for an application due authentication, custom controller actions, monitoring etc.
  • Caramel enforce carmel objects into the controller jags 

If there are improvements lets do it to Caramel.
-1 reasons for not improving Caramel are -
  • Caramel is all together a different concept. It's not about a front-end controller. It's about a dynamic template engine 
  • Caramel is kind of procedural where you have to evoke it from controllers
  • Caramel can be used in ways the developer wants. It's exactly opposing the idea of a framework. A framework exert certain things over developer. Caramel makes everyone write their own version of MVC (take Store and Publisher for an example.
 
We should not use two libraries in the platform as it will be a maintenance nightmare. So am -1 on developing applications in Absolute. If Caramel is missing functionalities that you desire, please add them to Caramel. 
I am suggesting to drop Caramel support and build a fully functional front-end controller. Caramel was built for something else and it shouldn't be continued because it's not really needed if you really look at it. Why - I am explaining below -

Why do you need a framework - You want to run the X logic on the Y request and display the Z representation to the user. In the world of frameworks - X is a controller, Y is the request, and Z is a display (view). Absolute simply allows you to match a controller to a view based on the user's request. The way you do it is up to you. You can use a conventional base approach as a pattern matching algorithm or a configuration approach.  The underlying framework requirement is just mapping logic to request and rendering representations. 


Regards,
/Nuwan


On Sun, Dec 1, 2013 at 11:45 PM, [hidden email] <[hidden email]> wrote:

Goose.js and Absolute.js training

Goose is a javascript framework for quickly writing APIs. Absolute is a front-end controller framework for jaggery for that can be used to build MVC type applications.

Goose.js - https://github.com/dulichan/goose.js
Absolute.js - https://github.com/dulichan/absolute.js

When
Tue Dec 3, 2013 1pm – 2pm Colombo
Where
3rd Floor Kernel Meeting room (map)
Calendar
[hidden email]
Who
[hidden email] - organizer
Shanmugarajah Sinnathamby
Kasun Dananjaya Delgolla
Gayan Gunawardana
Krishanthi Samarasinghe
Harshan Liyanage
Dilshan Edirisuriya
Niranjan Karunanandham
Dilan Jayakody
WSO2 Training Group

Going?   Yes - Maybe - No    more options »

Invitation from Google Calendar

You are receiving this courtesy email at the account [hidden email] because you are an attendee of this event.

To stop receiving future notifications for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.




--
Thanks & Regards,

Nuwan Bandara
Technical Lead; 
WSO2 Inc. 
lean . enterprise . middleware |  http://wso2.com 
blog : http://nuwanbando.com; email: [hidden email]; phone: <a href="tel:%2B1%20812%20606%207390" value="+18126067390" target="_blank">+1 812 606 7390




--
Chan (Dulitha Wijewantha) 
Software Engineer - Mobile Development
WSO2Mobile 
Lean.Enterprise.Mobileware
  ~Email       [hidden email]
  ~Mobile     <a href="tel:%2B94712112165" value="+94712112165" target="_blank">+94712112165
  ~Website   dulithawijewantha.com
  ~Blog         blog.dulithawijewantha.com
  ~Twitter     @dulitharw



--
Thanks & Regards,

Nuwan Bandara
Technical Lead; 
WSO2 Inc. 
lean . enterprise . middleware |  http://wso2.com 
blog : http://nuwanbando.com; email: [hidden email]; phone: <a href="tel:%2B1%20812%20606%207390" value="+18126067390" target="_blank">+1 812 606 7390




--
Senior Software Engineer

Mobile: <a href="tel:%2B94%2071%2082%20300%2020" value="+94718230020" target="_blank">+94 71 82 300 20




--
Gayan Gunawardana
Software Engineer; WSO2mobile Inc.; http://wso2mobile.com/
Blog: http://gayanj2ee.blogspot.com/



--
Senior Software Engineer

Mobile: <a href="tel:%2B94%2071%2082%20300%2020" value="+94718230020" target="_blank">+94 71 82 300 20




--
Chan (Dulitha Wijewantha) 
Software Engineer - Mobile Development
WSO2Mobile 
Lean.Enterprise.Mobileware
  ~Email       [hidden email]
  ~Mobile     <a href="tel:%2B94712112165" value="+94712112165" target="_blank">+94712112165
  ~Website   dulithawijewantha.com
  ~Blog         blog.dulithawijewantha.com
  ~Twitter     @dulitharw



--
Thanks & Regards,

Nuwan Bandara
Technical Lead; 
WSO2 Inc. 
lean . enterprise . middleware |  http://wso2.com 
blog : http://nuwanbando.com; email: [hidden email]; phone: <a href="tel:%2B1%20812%20606%207390" value="+18126067390" target="_blank">+1 812 606 7390




--
Ruchira Wageesha
Associate Technical Lead
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: [hidden email],   blog: ruchirawageesha.blogspot.com,   mobile: <a href="tel:%2B94%2077%205493444" value="+94775493444" target="_blank">+94 77 5493444





--
Ruchira Wageesha
Associate Technical Lead
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: [hidden email],   blog: ruchirawageesha.blogspot.com,   mobile: <a href="tel:%2B94%2077%205493444" value="+94775493444" target="_blank">+94 77 5493444




_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: Invitation: Goose.js and Absolute.js training @ Tue Dec 3, 2013 1pm - 2pm (dulitha@wso2.com)

Ruchira Wageesha
On Tue, Feb 4, 2014 at 7:47 AM, Samisa Abeysinghe <[hidden email]> wrote:
Can we please write this blog?  


Thanks,
Samisa...


Samisa Abeysinghe

Vice President Developer Evangelism

WSO2 Inc. 
http://wso2.com



On Mon, Dec 23, 2013 at 11:54 AM, Samisa Abeysinghe <[hidden email]> wrote:
Please send me the link once you do. 

Thanks,
Samisa...


Samisa Abeysinghe

Vice President Training 

WSO2 Inc. 
http://wso2.com



On Fri, Dec 20, 2013 at 12:44 PM, Ruchira Wageesha <[hidden email]> wrote:
On Fri, Dec 20, 2013 at 1:57 AM, Samisa Abeysinghe <[hidden email]> wrote:
Ruchira, would you like to get the below description and blog about it? 
Yes, I will do asap.

Thanks,
Samisa...


Samisa Abeysinghe

Vice President Training 

WSO2 Inc. 
http://wso2.com



On Tue, Dec 3, 2013 at 9:08 PM, Ruchira Wageesha <[hidden email]> wrote:
Hi All,

As most of the people argued here, caramel doesn't have a front-end controller functionality. Not having front-end controller pattern is neither a limitation in Jaggery nor caramel. Reason was we didn't implement it. That's why we have mentioned so many times to integrate it with goosejs or whatever and improve it. Further, caramel was initiated based on drupals UI block concept and improved to suite our environment/requirements.

caramel might have good points and bad points. What we need to do is keep the good, remove the bad and improve it. When you found some issue with carbon core, will you fix that and improve carbon core or will you introduce something else like carbon core? Then when someone else like you found another limitation in your new replacement, he will write his own. This will be continued like this for ever unless you are the smartest guy who developed it 100% perfectly for each and every requirement that comes even in the future. i.e. There shouldn't be any ticket for an improvement under your new framework.

But that's not the open source culture. If caramel/jaggery has problems, you can take the ownership and contribute. Both of them are Apache projects and no one is there to stop your contribution/commits. You can go ahead and improve wherever needed, that's the whole point of being it open source. It might be a complete re-write as we do with carbon 5. But still it should be CARBON and should have all the features/problems that we had addressed. Otherwise, when someone is using it for a long time, they will come up with older requirements and you will have to re-invent the wheel.

AFAIK, non-of the available frameworks don't directly addresses what we need. That's why we wrote caramel, just to give what we want and keep the rest as any developer wants. That's why either goose/frontend controller or whatever can be integrated to caramel. 

What caramel CORE enforces is, just passe all the data that you want render into caramel.render() method. That's it and you can have your own theming, templating language, goosejs etc. Its because we didn't think locking down your file structure or the whole app in a way that we wanted might not be good for everyone. 

You will probably say we have seen a particular structure which caramel enforces, reason was explained it in the caramel training, but for the people who wasn't there, will summarize here as well. 

caramel consists of caramel core and plugable engines where you can plug whatever engine with you own data to html rendering mechanism. By default caramel ships with handlebars based engine which enforces the above structure, that's what we developed for UES which can be again improved or write a new, better engine without touching the caramel core. Hope you have already seen [1].

Just to highlight why caramel was designed like that, please find the following.
  • Our webapps don't just target the end user, we have to target the developers as well. People should be able to get our store app and customize it as they want and give their clients. But still they should be able to get the updates that we provide with newer releases. If they have just edited our sources, then it will be problematic for migrations. 
  • Customization in the sense, they might be embedding new data like showing related amazon products etc., just re-theming or both.
  • Also, we needed to minimize the developer effort during the development lifecycle. i.e. If someone changed the store tag cloud with a nice HTML 5 canvas based UI, then he shouldn't be going through each and every page where tag cloud is being used, inserting whatever the thirdpart css/js libs that he wants. Further, any new page should be able to include the tag cloud UI with their own tags. They shouldn't need to worry about whether every dependent css/js are satisfied etc. i.e. UI elements should be modularized and should work in self contained manner.
  • Why caramel doesn't exert many things is, just because we don't like to lock down the developers, they should be free to go as they want. We can never think every single thing that a developer will do with a webapp, that's why that flexibility should be there.
  • In real usecases, Z(I am refering Z which described in dulitha's mail) consists of a1(js-1, css-1), a2(js-2, css-2), ....an(js-n, css-n) UI components and you will need to re-use the a1, a2.. in the views Z1, Z2...Zn where there are different pages. If someone updated z1 html and added a new JS file etc., then will I have to go and find where the z1 is used and update everything? Further, we shouldn't be including every dependent js/css in every page even though z1 is not being used in that page.
  • If a SAS app is being built, themes should be customizable by each tenant as they want. App developer shouldn't have to do much extra work to make that available.
  • Should be able to theme based on different roles, users etc.
  • It also has several other things like i18n support, ability to deploy in different contexts without changing any code, exposing all the raw data of a page or partially as a json for client side rendering etc. 
As I mentioned at the begining, caramel contains goods and bads. But all the above might being addressed better with your new framework. Hence you can take the ownership and improve/even completely re-write caramel with a very good architecture and feature set. But at the end, it should go under caramel, which WSO2 recommend and addresses the requirements a Jaggery developer, a WSO2 customer faces.



On Tue, Dec 3, 2013 at 5:42 AM, Nuwan Bandara <[hidden email]> wrote:
Hi 


On Tue, Dec 3, 2013 at 12:51 AM, Dulitha Wijewantha <[hidden email]> wrote:

Hi all,

My comments are inline. Other than that I wrote a sample blogger app that’s there for Caramel in Absolute. It’s found at [1]. My point is - I am willing to talk why Caramel approach is incorrect and why we need a Front-end controller. But folks- you got to be willing to listen. 

Its not about willing to listen, its just we were listening and talking about this for months and you always want to do your own framework, which will not work. How things should work is that if you need improvements in an already existing library / framework you can improve that while taking the good parts of it. 

From how I see it, Caramel has tons of very useful utilities we have written to support all the requirements of a large application (cacheing / i18n / templating / frontend-backend rendering / content negotiation etc etc  ). But what you are keep on complaining is not having a front controller. Am not against having a front controller its perfectly fine to have it, but have it in caramel and improve it so every one can use it. 

Also FYI FE-controller pattern is one of the patterns not THE way of doing things, the fact that you have worked with rails and thats how rails work doesn't justify that all frameworks should look like that. So please take a look at things and try to improve whats already there, Its always easy to write everything from scratch, but when we try to accommodate all the requirements things wont stay simple.

So shall we not waste time talking about it, but rather have a meeting and get whats useful from absolute and have it in Caramel and be done with it. 

@Chan please schedule a meeting with all interested parties, Myself and Ruchira are in EST

Also just FYI Caramel will be the way we will be writing jaggery Apps in WSO2, its like the carbon for java applications / components so anybody is welcome to contribute and improve the framework.

Regards,
/Nuwan
  

[1] - https://github.com/dulichan/absolute-example


PS:- I removed the training group since it’s an internal one. 

Peace~



On Tue, Dec 3, 2013 at 11:09 AM, Venura Kahawala <[hidden email]> wrote:
Hi,

I was not aware that filter concept was removed from jaggery, but we need to have a proper alternative so we can full fill basic needs of a basic web application.

@Nuwan: Could you please give an example on how a controller should be implemented given that my application adheres the caramel standards? If we can come up with a proper way of doing this, it will save a lot of time.  
Regards,
Venura


On Tue, Dec 3, 2013 at 10:55 AM, Gayan Gunawardana <[hidden email]> wrote:
Hi Venura,

We have discussed jaggery filter functionality few months back. You can find more information from [xacml with jaggery] mail thread in [hidden email]. We had the same requirement like how to implement Entitlement filter from jaggery side.

But the final conclusion was there are no filters in jaggery world, what you can do is, route all requests through one controller which will act as your filter 

Ain't this the Front-end controller?
 

I am totally +1 for considering these kind of existing features when implementing a new language.


On Tue, Dec 3, 2013 at 10:29 AM, Venura Kahawala <[hidden email]> wrote:
Hi Nuwan,

I'm new to jaggery world but while I was developing "my-identity" application for IS I found out some limitations in jaggery and Caramel.
What I needed was to implement a filter functionality just as in servlet filter. Purpose of the filter is described. When we have multiple pages and if some page should be restricted for some set of people based on the permissions, groups or some other factor, then we can intercept the request and validate within the filter. This is a basic requirement and it is pretty hard to implement that requirement in jaggery without adding a code segment to each page.

IMO we need to consider these kinds of existing features when implementing a new language. Yes as you mentioned, we need to improve the jaggery and Caramel instead of implementing functionality in separate places, but we should add these functionality since we are moving towards jaggery and caramel.

Regards,
Venura


On Tue, Dec 3, 2013 at 8:06 AM, Nuwan Bandara <[hidden email]> wrote:
Hi Dulitha,

We have had this debate over and over. What am trying to point out here is that we simply CANNOT have another way of writing jaggery apps.

+1 for not having another way to writing jaggery apps. But I don't agree that way to be Caramel. 
 
If we need improvements to Caramel please go ahead and contribute, don't create a new one that serves ur purpose. Caramel was there for sometime and APIM / UES / Store are build on that pattern.

We have used Store and Publisher both and found out that both of them are pretty inconsistent. Maybe Store and Publisher makes Caramel looks complex but I check the blogger sample and found that it's too over complicated. 
 
Front controller is sometimes good and sometime not so good, people will need multiple controller patterns at times. So please dont rely on just one pattern. 

We need multiple controller patterns. But we need a front-end controller. 


In a web app framework there are more things to think about, not just the controllers, most of the elements are well thought and included to caramel. So please take a moment and try to understand the framework and improve it as you need, but dont invent a new thing just for your cause.

The reason why we built absolute is to make writing jaggery apps pragmatic. Caramel is not pragmatic. We can't improve something when both concepts are different like Template engine and Front-end controller.  
 
and please think about the consistency when developing apps/components you cannot and should not just use random technologies here and there.

Random technology? Caramel is random technology. Absolute build on framework concepts found in Rails, Node etc (http://addyosmani.github.io/backbone-fundamentals/#mvc-applied-to-the-web)


Regards,
/Nuwan


On Mon, Dec 2, 2013 at 11:48 AM, Dulitha Wijewantha <[hidden email]> wrote:
Hi Nuwan,
My comments are inline. What I am proposing - is to build a fully functional front-end controller rather than just another template renderer. Let's have a discussion regarding this. I am also refactoring Absolute to provide capability to override how the pattern matching is done. This training is for anyone who is interested in these frameworks- mainly because they are pragmatic. 

On Mon, Dec 2, 2013 at 6:18 PM, Nuwan Bandara <[hidden email]> wrote:
Hi Chan,

We need to review the new security stuff you did for Goose.js (the routing library)

+1 for reviewing security of Goose.js. 
 
and also if we are doing any new jaggery application, we MUST follow caramel as that is the standard.
-1 for Caramel - below are my reasons 
  • Caramel is not really a framework. It's a template engine that does dynamic engine. It's an overkill for applications (that's not meant for overriding) 
  • A front end controller is required for an application due authentication, custom controller actions, monitoring etc.
  • Caramel enforce carmel objects into the controller jags 

If there are improvements lets do it to Caramel.
-1 reasons for not improving Caramel are -
  • Caramel is all together a different concept. It's not about a front-end controller. It's about a dynamic template engine 
  • Caramel is kind of procedural where you have to evoke it from controllers
  • Caramel can be used in ways the developer wants. It's exactly opposing the idea of a framework. A framework exert certain things over developer. Caramel makes everyone write their own version of MVC (take Store and Publisher for an example.
 
We should not use two libraries in the platform as it will be a maintenance nightmare. So am -1 on developing applications in Absolute. If Caramel is missing functionalities that you desire, please add them to Caramel. 
I am suggesting to drop Caramel support and build a fully functional front-end controller. Caramel was built for something else and it shouldn't be continued because it's not really needed if you really look at it. Why - I am explaining below -

Why do you need a framework - You want to run the X logic on the Y request and display the Z representation to the user. In the world of frameworks - X is a controller, Y is the request, and Z is a display (view). Absolute simply allows you to match a controller to a view based on the user's request. The way you do it is up to you. You can use a conventional base approach as a pattern matching algorithm or a configuration approach.  The underlying framework requirement is just mapping logic to request and rendering representations. 


Regards,
/Nuwan


On Sun, Dec 1, 2013 at 11:45 PM, [hidden email] <[hidden email]> wrote:

Goose.js and Absolute.js training

Goose is a javascript framework for quickly writing APIs. Absolute is a front-end controller framework for jaggery for that can be used to build MVC type applications.

Goose.js - https://github.com/dulichan/goose.js
Absolute.js - https://github.com/dulichan/absolute.js

When
Tue Dec 3, 2013 1pm – 2pm Colombo
Where
3rd Floor Kernel Meeting room (map)
Calendar
[hidden email]
Who
[hidden email] - organizer
Shanmugarajah Sinnathamby
Kasun Dananjaya Delgolla
Gayan Gunawardana
Krishanthi Samarasinghe
Harshan Liyanage
Dilshan Edirisuriya
Niranjan Karunanandham
Dilan Jayakody
WSO2 Training Group

Going?   Yes - Maybe - No    more options »

Invitation from Google Calendar

You are receiving this courtesy email at the account [hidden email] because you are an attendee of this event.

To stop receiving future notifications for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.




--
Thanks & Regards,

Nuwan Bandara
Technical Lead; 
WSO2 Inc. 
lean . enterprise . middleware |  http://wso2.com 
blog : http://nuwanbando.com; email: [hidden email]; phone: <a href="tel:%2B1%20812%20606%207390" value="+18126067390" target="_blank">+1 812 606 7390




--
Chan (Dulitha Wijewantha) 
Software Engineer - Mobile Development
WSO2Mobile 
Lean.Enterprise.Mobileware
  ~Email       [hidden email]
  ~Mobile     <a href="tel:%2B94712112165" value="+94712112165" target="_blank">+94712112165
  ~Website   dulithawijewantha.com
  ~Blog         blog.dulithawijewantha.com
  ~Twitter     @dulitharw



--
Thanks & Regards,

Nuwan Bandara
Technical Lead; 
WSO2 Inc. 
lean . enterprise . middleware |  http://wso2.com 
blog : http://nuwanbando.com; email: [hidden email]; phone: <a href="tel:%2B1%20812%20606%207390" value="+18126067390" target="_blank">+1 812 606 7390




--
Senior Software Engineer

Mobile: <a href="tel:%2B94%2071%2082%20300%2020" value="+94718230020" target="_blank">+94 71 82 300 20




--
Gayan Gunawardana
Software Engineer; WSO2mobile Inc.; http://wso2mobile.com/
Blog: http://gayanj2ee.blogspot.com/



--
Senior Software Engineer

Mobile: <a href="tel:%2B94%2071%2082%20300%2020" value="+94718230020" target="_blank">+94 71 82 300 20




--
Chan (Dulitha Wijewantha) 
Software Engineer - Mobile Development
WSO2Mobile 
Lean.Enterprise.Mobileware
  ~Email       [hidden email]
  ~Mobile     <a href="tel:%2B94712112165" value="+94712112165" target="_blank">+94712112165
  ~Website   dulithawijewantha.com
  ~Blog         blog.dulithawijewantha.com
  ~Twitter     @dulitharw



--
Thanks & Regards,

Nuwan Bandara
Technical Lead; 
WSO2 Inc. 
lean . enterprise . middleware |  http://wso2.com 
blog : http://nuwanbando.com; email: [hidden email]; phone: <a href="tel:%2B1%20812%20606%207390" value="+18126067390" target="_blank">+1 812 606 7390




--
Ruchira Wageesha
Associate Technical Lead
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: [hidden email],   blog: ruchirawageesha.blogspot.com,   mobile: <a href="tel:%2B94%2077%205493444" value="+94775493444" target="_blank">+94 77 5493444





--
Ruchira Wageesha
Associate Technical Lead
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: [hidden email],   blog: ruchirawageesha.blogspot.com,   mobile: <a href="tel:%2B94%2077%205493444" value="+94775493444" target="_blank">+94 77 5493444






--
Ruchira Wageesha
Associate Technical Lead
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: [hidden email],   blog: ruchirawageesha.blogspot.com,   mobile: +94 77 5493444


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: Invitation: Goose.js and Absolute.js training @ Tue Dec 3, 2013 1pm - 2pm (dulitha@wso2.com)

Nuwan Bandara-2
Hi Ruchira,

can you also put this on to [1] which is the caramel git readme.md



On Mon, Feb 10, 2014 at 6:46 AM, Ruchira Wageesha <[hidden email]> wrote:
On Tue, Feb 4, 2014 at 7:47 AM, Samisa Abeysinghe <[hidden email]> wrote:
Can we please write this blog?  


Thanks,
Samisa...


Samisa Abeysinghe

Vice President Developer Evangelism

WSO2 Inc. 
http://wso2.com



On Mon, Dec 23, 2013 at 11:54 AM, Samisa Abeysinghe <[hidden email]> wrote:
Please send me the link once you do. 

Thanks,
Samisa...


Samisa Abeysinghe

Vice President Training 

WSO2 Inc. 
http://wso2.com



On Fri, Dec 20, 2013 at 12:44 PM, Ruchira Wageesha <[hidden email]> wrote:
On Fri, Dec 20, 2013 at 1:57 AM, Samisa Abeysinghe <[hidden email]> wrote:
Ruchira, would you like to get the below description and blog about it? 
Yes, I will do asap.

Thanks,
Samisa...


Samisa Abeysinghe

Vice President Training 

WSO2 Inc. 
http://wso2.com



On Tue, Dec 3, 2013 at 9:08 PM, Ruchira Wageesha <[hidden email]> wrote:
Hi All,

As most of the people argued here, caramel doesn't have a front-end controller functionality. Not having front-end controller pattern is neither a limitation in Jaggery nor caramel. Reason was we didn't implement it. That's why we have mentioned so many times to integrate it with goosejs or whatever and improve it. Further, caramel was initiated based on drupals UI block concept and improved to suite our environment/requirements.

caramel might have good points and bad points. What we need to do is keep the good, remove the bad and improve it. When you found some issue with carbon core, will you fix that and improve carbon core or will you introduce something else like carbon core? Then when someone else like you found another limitation in your new replacement, he will write his own. This will be continued like this for ever unless you are the smartest guy who developed it 100% perfectly for each and every requirement that comes even in the future. i.e. There shouldn't be any ticket for an improvement under your new framework.

But that's not the open source culture. If caramel/jaggery has problems, you can take the ownership and contribute. Both of them are Apache projects and no one is there to stop your contribution/commits. You can go ahead and improve wherever needed, that's the whole point of being it open source. It might be a complete re-write as we do with carbon 5. But still it should be CARBON and should have all the features/problems that we had addressed. Otherwise, when someone is using it for a long time, they will come up with older requirements and you will have to re-invent the wheel.

AFAIK, non-of the available frameworks don't directly addresses what we need. That's why we wrote caramel, just to give what we want and keep the rest as any developer wants. That's why either goose/frontend controller or whatever can be integrated to caramel. 

What caramel CORE enforces is, just passe all the data that you want render into caramel.render() method. That's it and you can have your own theming, templating language, goosejs etc. Its because we didn't think locking down your file structure or the whole app in a way that we wanted might not be good for everyone. 

You will probably say we have seen a particular structure which caramel enforces, reason was explained it in the caramel training, but for the people who wasn't there, will summarize here as well. 

caramel consists of caramel core and plugable engines where you can plug whatever engine with you own data to html rendering mechanism. By default caramel ships with handlebars based engine which enforces the above structure, that's what we developed for UES which can be again improved or write a new, better engine without touching the caramel core. Hope you have already seen [1].

Just to highlight why caramel was designed like that, please find the following.
  • Our webapps don't just target the end user, we have to target the developers as well. People should be able to get our store app and customize it as they want and give their clients. But still they should be able to get the updates that we provide with newer releases. If they have just edited our sources, then it will be problematic for migrations. 
  • Customization in the sense, they might be embedding new data like showing related amazon products etc., just re-theming or both.
  • Also, we needed to minimize the developer effort during the development lifecycle. i.e. If someone changed the store tag cloud with a nice HTML 5 canvas based UI, then he shouldn't be going through each and every page where tag cloud is being used, inserting whatever the thirdpart css/js libs that he wants. Further, any new page should be able to include the tag cloud UI with their own tags. They shouldn't need to worry about whether every dependent css/js are satisfied etc. i.e. UI elements should be modularized and should work in self contained manner.
  • Why caramel doesn't exert many things is, just because we don't like to lock down the developers, they should be free to go as they want. We can never think every single thing that a developer will do with a webapp, that's why that flexibility should be there.
  • In real usecases, Z(I am refering Z which described in dulitha's mail) consists of a1(js-1, css-1), a2(js-2, css-2), ....an(js-n, css-n) UI components and you will need to re-use the a1, a2.. in the views Z1, Z2...Zn where there are different pages. If someone updated z1 html and added a new JS file etc., then will I have to go and find where the z1 is used and update everything? Further, we shouldn't be including every dependent js/css in every page even though z1 is not being used in that page.
  • If a SAS app is being built, themes should be customizable by each tenant as they want. App developer shouldn't have to do much extra work to make that available.
  • Should be able to theme based on different roles, users etc.
  • It also has several other things like i18n support, ability to deploy in different contexts without changing any code, exposing all the raw data of a page or partially as a json for client side rendering etc. 
As I mentioned at the begining, caramel contains goods and bads. But all the above might being addressed better with your new framework. Hence you can take the ownership and improve/even completely re-write caramel with a very good architecture and feature set. But at the end, it should go under caramel, which WSO2 recommend and addresses the requirements a Jaggery developer, a WSO2 customer faces.



On Tue, Dec 3, 2013 at 5:42 AM, Nuwan Bandara <[hidden email]> wrote:
Hi 


On Tue, Dec 3, 2013 at 12:51 AM, Dulitha Wijewantha <[hidden email]> wrote:

Hi all,

My comments are inline. Other than that I wrote a sample blogger app that’s there for Caramel in Absolute. It’s found at [1]. My point is - I am willing to talk why Caramel approach is incorrect and why we need a Front-end controller. But folks- you got to be willing to listen. 

Its not about willing to listen, its just we were listening and talking about this for months and you always want to do your own framework, which will not work. How things should work is that if you need improvements in an already existing library / framework you can improve that while taking the good parts of it. 

From how I see it, Caramel has tons of very useful utilities we have written to support all the requirements of a large application (cacheing / i18n / templating / frontend-backend rendering / content negotiation etc etc  ). But what you are keep on complaining is not having a front controller. Am not against having a front controller its perfectly fine to have it, but have it in caramel and improve it so every one can use it. 

Also FYI FE-controller pattern is one of the patterns not THE way of doing things, the fact that you have worked with rails and thats how rails work doesn't justify that all frameworks should look like that. So please take a look at things and try to improve whats already there, Its always easy to write everything from scratch, but when we try to accommodate all the requirements things wont stay simple.

So shall we not waste time talking about it, but rather have a meeting and get whats useful from absolute and have it in Caramel and be done with it. 

@Chan please schedule a meeting with all interested parties, Myself and Ruchira are in EST

Also just FYI Caramel will be the way we will be writing jaggery Apps in WSO2, its like the carbon for java applications / components so anybody is welcome to contribute and improve the framework.

Regards,
/Nuwan
  

[1] - https://github.com/dulichan/absolute-example


PS:- I removed the training group since it’s an internal one. 

Peace~



On Tue, Dec 3, 2013 at 11:09 AM, Venura Kahawala <[hidden email]> wrote:
Hi,

I was not aware that filter concept was removed from jaggery, but we need to have a proper alternative so we can full fill basic needs of a basic web application.

@Nuwan: Could you please give an example on how a controller should be implemented given that my application adheres the caramel standards? If we can come up with a proper way of doing this, it will save a lot of time.  
Regards,
Venura


On Tue, Dec 3, 2013 at 10:55 AM, Gayan Gunawardana <[hidden email]> wrote:
Hi Venura,

We have discussed jaggery filter functionality few months back. You can find more information from [xacml with jaggery] mail thread in [hidden email]. We had the same requirement like how to implement Entitlement filter from jaggery side.

But the final conclusion was there are no filters in jaggery world, what you can do is, route all requests through one controller which will act as your filter 

Ain't this the Front-end controller?
 

I am totally +1 for considering these kind of existing features when implementing a new language.


On Tue, Dec 3, 2013 at 10:29 AM, Venura Kahawala <[hidden email]> wrote:
Hi Nuwan,

I'm new to jaggery world but while I was developing "my-identity" application for IS I found out some limitations in jaggery and Caramel.
What I needed was to implement a filter functionality just as in servlet filter. Purpose of the filter is described. When we have multiple pages and if some page should be restricted for some set of people based on the permissions, groups or some other factor, then we can intercept the request and validate within the filter. This is a basic requirement and it is pretty hard to implement that requirement in jaggery without adding a code segment to each page.

IMO we need to consider these kinds of existing features when implementing a new language. Yes as you mentioned, we need to improve the jaggery and Caramel instead of implementing functionality in separate places, but we should add these functionality since we are moving towards jaggery and caramel.

Regards,
Venura


On Tue, Dec 3, 2013 at 8:06 AM, Nuwan Bandara <[hidden email]> wrote:
Hi Dulitha,

We have had this debate over and over. What am trying to point out here is that we simply CANNOT have another way of writing jaggery apps.

+1 for not having another way to writing jaggery apps. But I don't agree that way to be Caramel. 
 
If we need improvements to Caramel please go ahead and contribute, don't create a new one that serves ur purpose. Caramel was there for sometime and APIM / UES / Store are build on that pattern.

We have used Store and Publisher both and found out that both of them are pretty inconsistent. Maybe Store and Publisher makes Caramel looks complex but I check the blogger sample and found that it's too over complicated. 
 
Front controller is sometimes good and sometime not so good, people will need multiple controller patterns at times. So please dont rely on just one pattern. 

We need multiple controller patterns. But we need a front-end controller. 


In a web app framework there are more things to think about, not just the controllers, most of the elements are well thought and included to caramel. So please take a moment and try to understand the framework and improve it as you need, but dont invent a new thing just for your cause.

The reason why we built absolute is to make writing jaggery apps pragmatic. Caramel is not pragmatic. We can't improve something when both concepts are different like Template engine and Front-end controller.  
 
and please think about the consistency when developing apps/components you cannot and should not just use random technologies here and there.

Random technology? Caramel is random technology. Absolute build on framework concepts found in Rails, Node etc (http://addyosmani.github.io/backbone-fundamentals/#mvc-applied-to-the-web)


Regards,
/Nuwan


On Mon, Dec 2, 2013 at 11:48 AM, Dulitha Wijewantha <[hidden email]> wrote:
Hi Nuwan,
My comments are inline. What I am proposing - is to build a fully functional front-end controller rather than just another template renderer. Let's have a discussion regarding this. I am also refactoring Absolute to provide capability to override how the pattern matching is done. This training is for anyone who is interested in these frameworks- mainly because they are pragmatic. 

On Mon, Dec 2, 2013 at 6:18 PM, Nuwan Bandara <[hidden email]> wrote:
Hi Chan,

We need to review the new security stuff you did for Goose.js (the routing library)

+1 for reviewing security of Goose.js. 
 
and also if we are doing any new jaggery application, we MUST follow caramel as that is the standard.
-1 for Caramel - below are my reasons 
  • Caramel is not really a framework. It's a template engine that does dynamic engine. It's an overkill for applications (that's not meant for overriding) 
  • A front end controller is required for an application due authentication, custom controller actions, monitoring etc.
  • Caramel enforce carmel objects into the controller jags 

If there are improvements lets do it to Caramel.
-1 reasons for not improving Caramel are -
  • Caramel is all together a different concept. It's not about a front-end controller. It's about a dynamic template engine 
  • Caramel is kind of procedural where you have to evoke it from controllers
  • Caramel can be used in ways the developer wants. It's exactly opposing the idea of a framework. A framework exert certain things over developer. Caramel makes everyone write their own version of MVC (take Store and Publisher for an example.
 
We should not use two libraries in the platform as it will be a maintenance nightmare. So am -1 on developing applications in Absolute. If Caramel is missing functionalities that you desire, please add them to Caramel. 
I am suggesting to drop Caramel support and build a fully functional front-end controller. Caramel was built for something else and it shouldn't be continued because it's not really needed if you really look at it. Why - I am explaining below -

Why do you need a framework - You want to run the X logic on the Y request and display the Z representation to the user. In the world of frameworks - X is a controller, Y is the request, and Z is a display (view). Absolute simply allows you to match a controller to a view based on the user's request. The way you do it is up to you. You can use a conventional base approach as a pattern matching algorithm or a configuration approach.  The underlying framework requirement is just mapping logic to request and rendering representations. 


Regards,
/Nuwan


On Sun, Dec 1, 2013 at 11:45 PM, [hidden email] <[hidden email]> wrote:

Goose.js and Absolute.js training

Goose is a javascript framework for quickly writing APIs. Absolute is a front-end controller framework for jaggery for that can be used to build MVC type applications.

Goose.js - https://github.com/dulichan/goose.js
Absolute.js - https://github.com/dulichan/absolute.js

When
Tue Dec 3, 2013 1pm – 2pm Colombo
Where
3rd Floor Kernel Meeting room (map)
Calendar
[hidden email]
Who
[hidden email] - organizer
Shanmugarajah Sinnathamby
Kasun Dananjaya Delgolla
Gayan Gunawardana
Krishanthi Samarasinghe
Harshan Liyanage
Dilshan Edirisuriya
Niranjan Karunanandham
Dilan Jayakody
WSO2 Training Group

Going?   Yes - Maybe - No    more options »

Invitation from Google Calendar

You are receiving this courtesy email at the account [hidden email] because you are an attendee of this event.

To stop receiving future notifications for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.




--
Thanks & Regards,

Nuwan Bandara
Technical Lead; 
WSO2 Inc. 
lean . enterprise . middleware |  http://wso2.com 
blog : http://nuwanbando.com; email: [hidden email]; phone: <a href="tel:%2B1%20812%20606%207390" value="+18126067390" target="_blank">+1 812 606 7390




--
Chan (Dulitha Wijewantha) 
Software Engineer - Mobile Development
WSO2Mobile 
Lean.Enterprise.Mobileware
  ~Email       [hidden email]
  ~Mobile     <a href="tel:%2B94712112165" value="+94712112165" target="_blank">+94712112165
  ~Website   dulithawijewantha.com
  ~Blog         blog.dulithawijewantha.com
  ~Twitter     @dulitharw



--
Thanks & Regards,

Nuwan Bandara
Technical Lead; 
WSO2 Inc. 
lean . enterprise . middleware |  http://wso2.com 
blog : http://nuwanbando.com; email: [hidden email]; phone: <a href="tel:%2B1%20812%20606%207390" value="+18126067390" target="_blank">+1 812 606 7390




--
Senior Software Engineer

Mobile: <a href="tel:%2B94%2071%2082%20300%2020" value="+94718230020" target="_blank">+94 71 82 300 20




--
Gayan Gunawardana
Software Engineer; WSO2mobile Inc.; http://wso2mobile.com/
Blog: http://gayanj2ee.blogspot.com/



--
Senior Software Engineer

Mobile: <a href="tel:%2B94%2071%2082%20300%2020" value="+94718230020" target="_blank">+94 71 82 300 20




--
Chan (Dulitha Wijewantha) 
Software Engineer - Mobile Development
WSO2Mobile 
Lean.Enterprise.Mobileware
  ~Email       [hidden email]
  ~Mobile     <a href="tel:%2B94712112165" value="+94712112165" target="_blank">+94712112165
  ~Website   dulithawijewantha.com
  ~Blog         blog.dulithawijewantha.com
  ~Twitter     @dulitharw



--
Thanks & Regards,

Nuwan Bandara
Technical Lead; 
WSO2 Inc. 
lean . enterprise . middleware |  http://wso2.com 
blog : http://nuwanbando.com; email: [hidden email]; phone: <a href="tel:%2B1%20812%20606%207390" value="+18126067390" target="_blank">+1 812 606 7390




--
Ruchira Wageesha
Associate Technical Lead
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: [hidden email],   blog: ruchirawageesha.blogspot.com,   mobile: <a href="tel:%2B94%2077%205493444" value="+94775493444" target="_blank">+94 77 5493444





--
Ruchira Wageesha
Associate Technical Lead
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: [hidden email],   blog: ruchirawageesha.blogspot.com,   mobile: <a href="tel:%2B94%2077%205493444" value="+94775493444" target="_blank">+94 77 5493444






--
Ruchira Wageesha
Associate Technical Lead
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: [hidden email],   blog: ruchirawageesha.blogspot.com,   mobile: <a href="tel:%2B94%2077%205493444" value="+94775493444" target="_blank">+94 77 5493444




--
Thanks & Regards,

Nuwan Bandara
Technical Lead; 
WSO2 Inc. 
lean . enterprise . middleware |  http://wso2.com 
blog : http://nuwanbando.com; email: [hidden email]; phone: +1 812 606 7390


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture