Responding only to mifos-functional list-since my response relates only
to the functionality aspects of the email below...
>I have been working on this feature for a couple of days now,
>I thought I will update the group on my status and issues.
Thanks for the update, Chandan-- and sharing your ideas on your
approach.
>Please suggest improvements to this control flow/ structure...
>{I initially thought that the client family details could
>be put on the same page as the first page (had modified the jsp to
>reflect this thought process), but there was a opinion that the
>family details could be moved to a new page. I feel that this is a much
better idea.}
Given that GK is the only MFI (right now) who needs to fill out these
fields-- we need to make sure that turning on/off these additional
fields is configurable. We don't want to clutter up the create-client
pipeline with several new fields that aren't commonly used.
Given that, I don't think having a separate page makes sense. Because
most MFIs would disable/hide these fields, the page would be blank. (The
alternative, of course, is that you build it so the page only displays
if those fields are enabled-- but that approach seems too complicated
for simply adding additional fields).
Emily.
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Mifos-functional mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mifos-functional
