I think stores are fine when they can be used. None of my situations could
use stores as I don't use data aware type controls. Like you, one controls
data is Dependant on data from another control so I have to 'fetch' data
when needed. But many people could benefit from data stores that could be
connected to mock data, that would sure help out in lot of use cases.
Jim
On Sun, Oct 11, 2009 at 11:09 AM, panyasan <i...@bibliograph.org> wrote:
>
> Hello Jim,
>
> putting this on an extra thread so that it doesn't distract from Derrell's
> question...
>
>
> Jim Hunter-2 wrote:
> >
> > Christian,
> > You need to take a step back from your code for a minute and re-think
> > your
> > application. My application is about 10x the size of yours, and is 100%
> > data
> > driven and everything you see when it runs is generated on the the fly,
> > there are no pre-written screens. And my entire application is developed
> > using mock data and the server is tested separately from the client.
> There
> > is no need to see 'real' data while you are developing something, all you
> > need to know is what the data is going to 'look' like. Then create a
> > sample
> > set of data, or even a few sample sets and randomly return then if you
> > don't
> > want to always see the same thing. There is, IMHO, never a need to have a
> > connected back end as a requirement during development. You should always
> > be
> > able to use mocks on the client side, or at the least, have the mocks
> > served
> > up from the server until you get all your server code properly written.
> In
> > my job, mocks are essential to day-to-day development.
> >
>
> I believe you that this is probably the professional way to do things, no
> doubt, especially in teams. Because I have so little time (it is just a
> side
> project), the way I am working is to constantly adapt the server code to
> the
> needs of the client and vice versa - writing mockups would take much more
> time than just using the server data itself, which also alerts me to
> problems of the client-server communication as soon as they happen. That's
> probably not the best way to do things, but the only way I can
> realistically
> do it at the moment. So I am not arguing over philosophies here.
>
> But the interesting point is how this would affect and IDE - Thomas'
> original point. Wouldn't backend integration simply mean that you create
> visual objects for the "stores" and then connect them to whatever you want
> to connect them - mockup data or real server data?
>
> Cheers,
>
> Christian
>
> But the real question is
>
> --
> View this message in context:
> http://n2.nabble.com/qooxdoo-IDE-Request-for-Comments-tp3782909p3804194.html
> Sent from the qooxdoo mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> 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
> _______________________________________________
> qooxdoo-devel mailing list
> qooxdoo-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
------------------------------------------------------------------------------
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
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
