Thanks Angshuman for the post. I cant agree more with you. The
discussion topic is such that it deserved a long post.
Hi Shahzada, Thanks for sharing your point of view. Here are some of
the observations that I have from my experience.
True, Javascript libraries have to be sent to the client using either
a jsp or servlet. But thats all the jsp could be used for. I have been
attracted to javascript libraries for some time now. And in a recent
project I worked on a prototype to develop the pages that had been
developed using jsp tags with ajax retrofitted into it, using ext-js
javascript library. The experience was refreshing and an eye-opener
for me. I realized the power of these libraries. I believe that you
can do pretty much everything in view using these libraries. These
libraries have been designed very well and you can see a clear
separation of responsibilities between objects in these libraries (Its
a kind of mvc pattern implementation). The code that I had written
using ext-js library was much more cleaner, simpler and easier to work
with than the code that was in jsps.
These libraries do have a learning curve but once you get used to the
library and its design, it is very simple to create views.
Thanks,
Virender
On May 21, 6:33 am, Angshuman Sarkar <angs...@...> wrote:
> My 2 cents:
> I believe each web application should be *designed* and decide on *tech
> stack* for what needs to be done.
> There is no one-size fits all. The tools and technologies to build almost
> all complex webapplications have been there for long, still we do
> deliberation on choosing the technology - mainly to see whats right, what
> suits, whats best given the requirements from business.
>
> Even the web application, how it needs to be built is to be thought of
> carefully. Should we go with a MVP or a MVC pattern? A component oriented or
> action based framework? Would apache wicket give me speed of development?
> sure, would it increase my resource requirements, as it keeps memory
> footprint for component-trees on server?
>
> Other examples, would you choose a portlet mechanism if there is no
> personalization requirement? If you do require, probably spring portlet MVC
> is good choice. Do we require re-usable widgets on pages, like say an
> e-Commerce site like ebay? Maybe a StringTemplate and JavaScript/JSON based
> solution is suited best. On such cases, do we go with a page controller
> approach, leading to duplication of code? Or maybe a chain-of-controllers
> pattern is better suited!
> Would I need to aggregate information from multiple datasources (some even
> from outside my domain), maybe a mashup/aggregator approach is best. Maybe I
> would even think of a RESTful architecture.
>
> Therefore, I would always go back to business and ask them what they want
> and envisage, try to have detailed understanding of interface requirements
> of business, decipher the technical aspects and then evaluate different
> solution approached.
>
> I have been involved with few projects, where we would just download the
> page template (simple string based, just placeholders and containers, of
> simple XHTML markups). We used REST apis to connect to server, fetch data,
> bind to controls - set up an MVC approach on the UI front. (oh yes!)
> It was the perfect solution for websites very complicated, with thousands
> and thousands of concurrent users. It worked brilliantly. Can mifos benefit
> from such clean web architecture? sure. Does mifos need such an
> architecture? I am not sure. Will it justify the cost-benefit for the
> effort to setup such an architecture? Maybe not.
>
> JavaScript is a brilliant language and as Doug Crockford said it many times
> .. "the most misunderstood language of all". Its completely OO , dynamic and
> functional language. (Albeit with deficiencies introduced during 1993-1997,
> during the browser-war, with many *great* companies reverse engineering
> netscape implementation and other gang being arrogant and stubborn). It
> gives you extremely power but its a paradigm shift from classical objection
> oriented approach. In my experience of using javascript extensively, I have
> seen even otherwise brilliant developers make total mess with javascript.
> Honestly, if I hadn't used javascript for non-web work, I probably would
> have never realized its power and understood the language.
>
> And thats mainly my hesitation of building a javascript driven MVC pattern
> with/without markups for templates. Maintenance of JavaScript is another
> aspect.
> its odd that an language so widely used, it still lacks from tools support.
> Sure aptana and various editors help to certain extent. Consider debugging,
> other than firebug, there is no decent debugger at all. (I am not even
> considering iexplorer 8 developer tools but from time and time had to resort
> to that!) Testing is another aspect to consider, although screwunit,
> jstester help to great extent these days.
>
> Essentially I think it requires a different mindset/paradigm to build
> applications completely over JavaScript. However if you would ever want to
> do so, consider me in. ;) I would love that.
>
> quite a long post .. my 2.5 cents!
> regards
> ~angshu
>
>
>
> On Thu, May 13, 2010 at 7:43 PM, Shahzada Hatim <geoa...@...> wrote:
> > Hello,
>
> > @virender
>
> > Javascript libraries cannot replace what JSPs do(or GSPs if its Grails) ,
> > you still need to send in the payload of Javascript from some where. Doing
> > every thing related to view in Javascript is not fesible for Mifos (please
> > correct me if I am wrong)
>
> > The license of ExtJS needs to be investigated, I have been warned about it
> > before.
>
> > Dojo and Jquery are both popular with Springsource (company behing Spring
> > and Grails) and Jquery had gotten lots of traction in the last few months
> > with support from the dark side of the force as well. So they can serve as
> > "cherry toppings", but I dont believe the entire view should be done.
>
> > 4. These libraries use object oriented javascript so the code is clean
> >> and maintainable. Developer can also create reusable UI widgets/
> >> components.
>
> > I am convinced that introduction of javascript in any project means more
> > complextity overall so I don't agree with No 4.
>
> > both in Spring (roo) and Grails there is nothing stopping from use of
> > Javascript libraries, although it would mean lots of integration by hand.
> > Spring roo is experimenting with GWT based CRUD generation these days and I
> > suspect Grails will catch on that too soon. But Javascript based UI will
> > mean lots of pain overall
>
> > As a rule of thumb, what ever can be done in plain HTML can be replicated
> > to Javascript/Ajax/Comet based solution later, giving you graceful
> > degradation.
>
> > PS: these are just my 2 cents, based on work on other projects
> > --
> > Shahzada Hatim
> > GSoC Student 2010 - Mifos
>
> > On Thu, May 13, 2010 at 4:42 AM, virender <virendersin...@...:
>
> >> Hi Keith,
>
> >> I was interested in knowing if we have considered other technologies
> >> for UI. I am specifically interested in knowing if we have considered
> >> javascript libraries such as ext-js, JQuery, Dojo etc. These libraries
> >> provide a number of benefits over jsps:
>
> >> 1. Performance Gain: Html content generation is done by the browser.
> >> The server does not need to waste its cpu for generating html content.
> >> The javascript code asks server only the data that the UI needs or to
> >> execute any action on behalf of the user.
> >> 2. These libraries provide a rich set of widgets, UI controls, layouts
> >> etc. I believe most of the UI can be easily developed with out-of-
> >> shelf widgets and support.
> >> 3. These libraries use ajax behind the scene and so provide a better
> >> user experience.
> >> 4. These libraries use object oriented javascript so the code is clean
> >> and maintainable. Developer can also create reusable UI widgets/
> >> components.
> >> 5. A number of development tools such as firebug etc are available
> >> that make development and debugging in javascript easier.
>
> >> I don't know about grails and how javascript libraries stand vis-a-vis
> >> grails.
>
> >> Regards,
> >> Virender
>
> >> On Mar 23, 9:12 am, Keith Woodlock <keithwoodl...@...> wrote:
> >> > Krishnan,
>
> >> > Thanks for the comments. I'll try to answer you questions:
>
> >> > >>> a) The POJOs from the domain model that represent things like
> >> customers,
>
> >> > branches, loans, etc. are typically required across>>> multiple layers,
> >> and in the UI as well. Hopefully, we won't have
>
> >> > multiple sets of closely related objects in the different layers
>
> >> > >>> and "marshall"-ers that convert between them...
>
> >> > We are aiming for a clean layered architecture where design dependencies
> >> > flow in one direction. Currently in mifos this is not the case which
> >> causes
> >> > a great deal of difficulty during development (+ automated testing). So
> >> yes,
> >> > the intention is to pass only DTOs up to a 'Dumb UI'. We are doing this
> >> as
> >> > we want to isolate the layer we feel is most important - the domain and
> >> stop
> >> > changes in the domain rippling up to UI. I understand that for CRUD
> >> > operations, you typically want changes in the domain to be reflected in
> >> the
> >> > UI but we are happy to incur the cost of 'translating' our 'Entities' to
> >> a
> >> > Data object (DTO). Value Objects on the other hand we may choose to
> >> allow
> >> > back up to the UI but for now we are simply saying that it is DTOs being
> >> > passed up to a 'Dumb UI'
>
> >> > >>> i presume the comment "shields UI from domain" and vice-versa is the
>
> >> > same as "shields UI from business logic", etc.
>
> >> > Yes, we mean shielding the UI from any business/domain logic or any
> >> > knowledge of business/domain entities/services etc.
>
> >> > >>> b) Do i see Grails scribbled...exciting...
>
> >> > Yes there are some on going spikes using Grails for rewriting our
> >> UI/MVC..
>
> >> > >> c) Are we thinking of something special to support reporting?
> >> Reporting
>
> >> > deserves special attention, and reporting needs a
>
> >> > >> beeline to the database.
>
> >> > There architecture drawing in question was only focusing on the
> >> difference
> >> > between current mifos and future mifos with respect to its domain model
> >> and
> >> > services and clients that use these services such as the web ui and
> >> other
> >> > third party applications.
>
> >> > As you say reporting deserves special attention and it is in our
> >> technology
> >> > plan but maybe others will be able to tell you more about the direction
> >> > there..
>
> >> > Hope this helps.
>
> >> > Regards,
> >> > KeithW
>
> >> > On Tue, Mar 23, 2010 at 6:52 AM, Krishnan M <kml...@...> wrote:
> >> > > The diagram for the new architecture is interesting. Couple of
> >> > > comments/questions...
>
> >> > > a) The POJOs from the domain model that represent things like
> >> customers,
> >> > > branches, loans, etc. are typically required across multiple layers,
> >> and in
> >> > > the UI as well. Hopefully, we won't have multiple sets of closely
> >> related
> >> > > objects in the different layers and "marshall"-ers that convert
> >> between
>
> ...
>
> read more »
>
> --------------------------------------------------------------------------- ---
>
> --
> You received this message because you are subscribed to the Google Groups "Mifos Developer" group.
> To post to this group, send email to mifosdeveloper@....
> To unsubscribe from this group, send email to mifosdeveloper+unsubscribe@....
> For more options, visit this group athttp://groups.google.com/group/mifosdeveloper?hl=en.
|