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. 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 <yark...@gmail.com> 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 <rbspg...@gmail.com> 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 <mdipie...@cs.depaul.edu> wrote: > > > On Jul 9, 11:04 pm, rb <rbspg...@gmail.com> 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 web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
