I understand that Rb does something like I am doing: uses web2py with SQLite for standalone mode; without a server. At least this feature initially convinced me to try web2py. This make a very appealing proposition: use simple, easy to use tools (python + html) to develop a cross-platform application with quite rich user interface, and who cares that it's technically a web app. That he calls a thick client. Is that true?
I started with this but quickly went beyond SQLite capabilities, so my app has turned into full blown intranet application with oracle backend, but I still advertize its demo version as standalone app. I wrote once a while ago when we discussed killer apps for web2py, that there is quite a market for standalone application based on web technologies and basically all we need to add is a native platform wrapper for browser that automatically runs web2py server and opens browser at localhost:8000. Sorry for offtopic. On Jul 10, 11: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 -~----------~----~----~----~------~----~------~--~---
