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 -~----------~----~----~----~------~----~------~--~---
