+1 for the Boilerplate structure. Speaking of sharing JS libraries, I think AngularJS[1] would be a perfect fit as you can define services and modules and share them between different webapps easily. It has a sharp learning curve, but once you get used to it, it should be fun to code with.
Also I suggest we use Twitter Bootstrap[2] for the look and feel. [1] http://www.angularjs.org/ [2] http://twitter.github.io/bootstrap/index.html Thanks Viknes -----Original Message----- From: Sanchit Aggarwal [mailto:[email protected]] Sent: Tuesday, June 25, 2013 10:55 AM To: [email protected] Subject: Re: SVN repo for GSOC projects +1 Danushka , we can have a utilities folder under the JS folder itself and from there the shared JS libraries can be used. Regards Sanchit Aggarwal MS Research (Computer Science) Center for Visual Information Technology IIIT Hyderabad, Gachibowli Contact - 9581417330 On Tue, Jun 25, 2013 at 11:49 AM, Danushka Menikkumbura < [email protected]> wrote: > Maybe it is a deployment model is it? > > > On Tue, Jun 25, 2013 at 11:46 AM, Danushka Menikkumbura < > [email protected]> wrote: > > > +1. > > > > How would you use shared JS libraries in this boilerplate BTW?. > > > > Cheers, > > Danushka > > > > > > On Tue, Jun 25, 2013 at 11:36 AM, Subho Banerjee > ><[email protected] > >wrote: > > > >> I would like to suggest a slightly different layout. Particularly > because > >> the logic for the UI for Workflow composition and Workflow > >> composition itself in HTML are not seperate. Also, I am following > >> the HTML5 Boilerplate to structure my front end code[1], so this > >> means that code which I write for the workflow composition UI is > >> structured as follows - > >> > >> /:. > >> ├───index.html > >> ├───css > >> └───vendor > >> ├───doc > >> ├───img > >> └───js > >> ├───vendor > >> ├───model > >> └───controlers > >> > >> Now, the js folder contains all the front end logic for the UI as > >> well > as > >> workflow composition. I would suggest that we follow this structure > >> and not further subdivide the web UI module. In which case, we can > >> reuse objects in between the various web-ui sub-projects. > >> > >> Cheers, > >> Subho. > >> > >> > >> [1] http://html5boilerplate.com/ > >> > >> > >> On Mon, Jun 24, 2013 at 11:47 PM, Danushka Menikkumbura < > >> [email protected]> wrote: > >> > >> > Hi Suresh, > >> > > >> > I think we need to have the following structure. > >> > > >> > 1. web-gui (xbaya-web-ui?) - The Web UI would be a top-level > >> > module, > >> under > >> > which we may have the following sub modules. > >> > > >> > - ui (Widgets, graph, canvases, etc) > >> > - workflow (Workflow composition, execution) > >> > - monitor (Workflow monitoring) > >> > - protocol (XML/JSON protocol conversion module) > >> > > >> > 2. ws-messenger.client.protocol.amqp - AMQP client API bits > >> > > >> > 3. xbaya-gui.ui - AMQP configuration + monitoring. > >> > > >> > Sanchit, Shameera, Subho, Vijayendra and Viknes, what do you think?. > >> > > >> > Thanks, > >> > Danushka > >> > > >> > > >> > > >> > On Sun, Jun 23, 2013 at 6:16 PM, Suresh Marru <[email protected]> > >> wrote: > >> > > >> > > Hi All, > >> > > > >> > > Please discuss how should we structure the SVN repo for gsoc > projects? > >> > > certainly not by student since every one is contributing to > >> > > master > >> > project. > >> > > So may be the functional components? > >> > > > >> > > I created a sandbox area, please discuss how individual modules > >> should be > >> > > organized and please create JIRA's and submit patches to this repo. > >> > > > >> > > https://svn.apache.org/repos/asf/airavata/sandbox/gsoc2013 > >> > > > >> > > Suresh > >> > > > >> > > > >> > > >> > > > > >
smime.p7s
Description: S/MIME cryptographic signature
