On Fri, Jul 10, 2009 at 3:40 AM, rb <[email protected]> wrote: > > Interesting post, Yarko. I think Sergey has a good idea of what I'm up > to (gee, I didn't discover/invent this?;-) > > My plan is to use web2py to provide the business logic and db, ie "the > server" functionality, although it will co-exist on the same machine > as the thick client (until the project moves along quite a bit). > However, I distinguish the diff between a thick and thin client not by > where I place the business logic (the only logic on the client is > validation-code) but by what means (or protocol) the high-speed > interaction of the user input/feedback with the business logic takes > place (whew!). For a clarification of that last sentence consider a > simple webpage with an html form. It is the prototypical thin client > because there is (almost) no client side logic. In comes ajax and > google and you have a whole ecosystem of ajax technologies (like > Google Web Toolkit) which can greatly speed up the interaction of the > thin client with the user - using javascript, the web browser can now > run client side logic, yet we still call this a "thin" client - even > if that muddies the waters. A thick client, because it has great > client side code-power, can have all sorts of fancy-shmancy widgets > (we'll ignore Google and their GWT for now), that can interact at high > speed with the user. If this client only does (rudimentary) validation > of input and sends the bulk of the raw data over to the server, where > business logic there processes it then I call this a "thick" client > and (I assert) it is not rally doing any more of the business logic > than the thin client, it's just much faster interacting with the user.
Ok - I understand you now - this is still thin client, I think, at least by what I know, and by: http://en.wikipedia.org/wiki/Fat_client http://en.wikipedia.org/wiki/Thin_client and many other references... Regardless, you are trying to use something other than a browser for the client end (if I recall), so that does deserve some extra discussion, as the view part of web2py assumes an html / xhtml client (that's what it generates to send out the wire, that's the protocol. > > > So, before the advent of ajax, the choice was between simplistic (and > slow) thin clients (that required no deployment) and fast, fancy, > interactive thick clients that required deployment and complicated/low- > level communication protocols (like sockets). Today the choice seems > (to me) to be to use ajax and thin clients. However, I'm new to this > web programming gig (previous experience in CRUD apps and systems > programming) and I worked thru Google's GWT example app on line. > OH_MY_GAWD. You've GOT to be kidding me. To generate an app which has > a textbox and can populate a list from entries in the textbox which > pretends to be a stock ticker with a timer that fires to update > (random) deltas in the stock price involves PAGES of code. Great > heaping GOBS of code. Code of all manner. CSS stuff, XML, blah blah > blah. My old company has a team of twenty writing their ajax/GWT > platform for their app and they've been at it for 6 months now - > they're now getting ready to hand the SDK over to the app > programmers. > > I don't have the resources for ajax thin client programming. I'll > stick with the trials of deploying the thick client. > > But wait, I'll also need to generate lots of "reports" and you could > burn me with fire before I'll slog through using Crystal Reports for > this. No, I can use Web2py and python and code up some html reports > from the db. The entry forms and inquiry forms of the thick client I'm > doing in wxPython will work fine. I can use xmlrpc for the client-to- > svr protocol. Who cares if its grossly slow ? (even though I'm led to > believe that it's not so slow) if it's all on the same machine. > However, the customer wants to see his reports from his browser out on > the 'net somewhere. How can I deliver such? Oh look, there's web2py. > Awesome. In a few short days of reading even *I* can understand how to > hack something together - and I'm just starting (in python). I've > still got to watch out for the speed of communication issue but that's > tomorrow's problem and there won't be a tomorrow if I have to use > ajax. > > But again, I'm kinda new to all this stuff, so I stand to be corrected > if I'm being naive... ;-) > > --- > Rb > > > > On Jul 10, 12:31 am, Yarko Tymciurak <[email protected]> wrote: > > I just have to point this out: by definition (at least some) thick > clients > > operate regardless of being connected to a network or not... > > > > So - here's anther way to talk about that concept; Given a network > > architecture something like this: > > > > Presentatoin > > ---------- > > Logic > > -------- > > Data persistence or device layer > > > > (and we could show this as 4 or 5 layers, but the point remains the same) > > it is a design choice where you put the network boundray. > > > > Presentation > > ------< network >------ > > Logic > > ------------ > > Data Layer > > > > would be what is typically called a thin client: the business and > > engineering logic is on the server; you can't run without it. > > In web2py terms, the models and controllers are the two server layers. > > > > Now, this change: > > > > Presentation > > ------------- > > Logic > > -------< network >------ > > Data Layer > > > > would be the fundamental change that would make for a thick / rich > client. > > > > Now, it can get fuzzy in the details - Flash (for example) is a rich > client > > which runs symbiotically with a "rich" server, BUT for these purposes, a > > flash application in your browser (however rich) does not make for an > > application that can run free of the network. > > > > SO - my point is this: web2py is a server-based application host, for > use > > with what would normally be called thin clients. > > > > That is not to say that you could not have a thick client that would > > interact symbiotically with a web2py server, but I would think that would > be > > through services. > > > > When I read your question, and your statement about thick client, and how > > you get web2py to work with it, I cannot help but wonder - whcih are you > > doing --> building a thick client, or building a web2py application? (Of > > course you could be doing both, but that would be somewhat a special > case, > > and interesting in more details and discussion). > > > > Regards > > > > - Yarko > > > > On Fri, Jul 10, 2009 at 1:55 AM, rb <[email protected]> wrote: > > > > > Thx for the speedy reply. Here's another question: > > > > > 3) Because I'm doing a thick client, it creates db queries (SQL CRUD) > > > which need to be communicated back to the controller which must query > > > the db. The two ways to do this are: > > > > > a) use a SQL statement within a executesql command, or > > > > > b) create a DAL row selection criteria string and a column selection > > > criteria string, send them back to the controller which feeds them > > > through a python eval statement within a DAL function. > > > > > It is always pointed out that b) is dangerous because it's possible > > > for unintended string matter to get fed into the eval - which can reek > > > havoc. However only *my* strings from the client which I have > > > carefully massaged will ever be sent (e.g. I collect the column names > > > from the db beforehand and provide them to the db().select(<fieldnames- > > > here>) statement). Further, if I craft a SQL string then it too can > > > suffer from bad input. I just have to be extra careful when creating > > > the query strings. > > > > > However if I use a) then I lose all of the functionality provided by > > > the DAL. I've never been a fan of SQL and I'd like to avoid it in > > > favour of what the DAL can offer. > > > > > So I've implemented b) and it is working. My questions are: > > > > > i) am I missing the obvious? Is there a much simpler/better way to do > > > this? > > > ii) does the DAL add much overhead? > > > > > On Jul 9, 9:21 pm, mdipierro <[email protected]> wrote: > > > > On Jul 9, 11:04 pm, rb <[email protected]> wrote: > > > > > > > Hi all, > > > > > > > I'm using Web2py to serve a wxPython thick client via XMLRPC. I'm > > > > > currently using SQLite (I like the zero db config ;-) and I have a > few > > > > > questions: > > > > > > > 1) I have missed how to specify table constraints across several > > > > > fields (in SQLite). For example, in a table the primary key > consists > > > > > of two fields - how do I specify that these two fields must > comprise a > > > > > UNIQUE value? In other dbs I could use executesql to just give the > SQL > > > > > commands, but SQLite (unless I'm mistaken) only allows table > > > > > constraints within the CREATE TABLE SQL command. So can this be > done > > > > > in Web2py? > > > > > > You cannot create such constraint database side from > > > > web2py. Your options are: > > > > 1) enforce the constraint at the validators level > > > > 2) create the table outside web2py and set migrate=False > > > > > > > 2) I'm confused as to which models get run when a controller is > > > > > accessed. If I have db.py and uom.py models and I access the uom > > > > > controller, what happens? From stepping thru the debugger I saw > db.py > > > > > get run first, then uom.py and then uom.py again (weird). I've > > > > > simplified things down to just one (db.py) file for now, but I'm > > > > > wondering if the infrastructure's intent is to run all model files > > > > > upon each and every controller access. Oh, my access of the > controller > > > > > is via XMLRPC function (if that changes anything). > > > > > > All of them. Alphabetically. There has been some discussion on > whether > > > > there should be exceptions to this rule. It would be easy to > inplmenet > > > > but there was no consensus on whether an improvement was necessary. > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py Web Framework" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
