I have a lot of this working but I am stuck on getting individually submitted values from the request...
the model: http://pastebin.com/d2ddf4718 the controller: http://pastebin.com/d74b1a1e2 the 'tonight' view: http://pastebin.com/d6746076d the tonight view and the create view are working... the view only shows the latest event for that day for all users... it also provides a button for attend/unattend for each event. It is the toggle_attendance function I am having trouble with. I am missing something very fundamental about using POST variables in web2py. I looked around in the docs (at the least the latest chapters 6,7,8). Looking at the view should reveal what it is i am trying to do. I just want to use the event_id value in the POST to check the attendance table for an existing record for that event/user combo and delete it if it is there (unattend) or add it if it is not (attend). On Jul 29, 10:13 pm, mdipierro <mdipie...@cs.depaul.edu> wrote: > If you build the model, and empty actions which a docstring explaining > what the should do, I can help filling the blanks. > > On Jul 29, 8:37 pm, __future__ <wrigh...@gmail.com> wrote: > > > I would like it to be functionally as similar to the original as > > possible (with maybe a couple of enhancements :-) ) > > > I think in the building of it, people will really appreciate a lot of > > the things that web2py does for you in the process.. I personally find > > seemingly little things like the handling of routes and default views > > extremely helpful in the process of actually making/testing things. > > > I was actually wondering about the latest field as I was posting all > > of those examples... It has been almost a year since I walked through > > thatDjangotutorialand I think it had something to do with the > > archive or maybe the following behavior.. In any case, until I look > > into it, I can't really argue for its purpose... though I think it was > > necessary for some reason. > > > I don't think GAE is really important to this example. Not everything > > worth doing is going to be GAE friendly and I think this is a good > > case study for some of the features it exposes like the > > '"twitteresque" following behavior, etc.. > > > I also like that it givesDjangopeople a 1-1 comparison of how to > > accomplish similar behavior with a different philosophy (as you say). > > > Thanks for offering your help. > > > On Jul 29, 8:20 pm, mdipierro <mdipie...@cs.depaul.edu> wrote: > > > > This is an excellent idea and you can count on my help. > > > > One decision you need to make is how close you want to the > > > "translation" to be to the original. > > > - do you need the same actions? (I assume yes) > > > - can you use joins? (I assume yes, but in this case it will not run > > > on GAE) > > > - do you need the same tables? (probably yes) > > > - do you need the same table and field names? (I would change some of > > > them) > > > - Why do you need the latest field? I think this is redundant since > > > you can select the latest using the post date. > > > - How should users search for other users to follow? (by name, by > > > email, by secret code) > > > > On Jul 29, 7:44 pm, __future__ <wrigh...@gmail.com> wrote: > > > > > Thank you for the quick reply! > > > > > I think this is starting to click a little more for me. I have > > > > purchased the book and I have the updated chapters you posted for > > > > 6,7,8 that I have been using as a reference. > > > > > Unfortunately, my mind struggles with abstractions unless presented > > > > with a concrete example. It is probably why I am still a mediocre > > > > programmer after all of these years :) > > > > > Could you possibly assist me with some more hints along these lines... > > > > you can check out the working end result of all of that djangoese at: > > > > >http://startthedark.com > > > > > My ultimate goal is to rebuild that app in web2py and describe the > > > > process in detail along with screencasts. This startthedark was a > > > > project based on adjangoscreencasttutorialseries called "Django > > > > from the ground up" that I found very useful when learningDjango. > > > > > Thanks for all of the help. > > > > > __future__ > > > > > On Jul 29, 7:11 pm, mdipierro <mdipie...@cs.depaul.edu> wrote: > > > > > > These are good questions. web2py does not have something likeDjango > > > > > managers and you have to achieve the same goal differently. This is > > > > > because of different in design philosophy. > > > > > >Djangohas an ORM, web2py has a DAL. InDjangoa model maps a table > > > > > into an object so you can override the methods of that object. > > > > > web2py prefers to be a lower lever than that. the web2py DAL > > > > > expressions map 1-to-1 into SQL queries. For example we do not have a > > > > > save() methods. We do have an insert() method. You cannot override it > > > > > because it does not belong to the table (model) but it belong to the > > > > > database. (technically you could override it but you would be doing > > > > > for all tables). > > > > > > What inDjangoyou achieve by modifying the model, in web2py you > > > > > achieve my modifying the forms. Forms can be associated to two > > > > > functions: onvalidation, onaccept. The former is executed after > > > > > validation before any database IO, the latter is executed after > > > > > database IO. > > > > > > You can define these functions in the model (they are just functions, > > > > > not class methods) but you still need to be specific about which form > > > > > they apply to (onvalidation=...). > > > > > > Hope this helps. > > > > > > Massimo > > > > > > On Jul 29, 3:18 pm, __future__ <wrigh...@gmail.com> wrote: > > > > > > > Looking at my post, I can see where not knowingDjangowould be an > > > > > > impediment to understanding... :) > > > > > > > Let me try again (and please bare with me because I am *not* an > > > > > > expert > > > > > > onDjango). > > > > > > >Djangohas these things called Managers: > > > > > > >http://docs.djangoproject.com/en/dev/topics/db/managers/ > > > > > > > from theDjangodocs: > > > > > > > class Manager > > > > > > > A Manager is the interface through which database query operations > > > > > > are > > > > > > provided toDjangomodels. At least one Manager exists for every model > > > > > > in aDjangoapplication. > > > > > > > You can create your own Managers and use them with your models. You > > > > > > can create custom QuerySets (filters basically) and use them with > > > > > > your > > > > > > Managers. > > > > > > > In the example I gave, he creates a function today(): > > > > > > > from datetime import datetime, timedelta > > > > > > def today(): > > > > > > now = datetime.now() > > > > > > start = datetime.min.replace(year=now.year, month=now.month, > > > > > > day=now.day) > > > > > > end = (start + timedelta(days=1)) - timedelta.resolution > > > > > > return (start, end) > > > > > > > Then a custom QuerySet (EventQuerySet) that extends the base > > > > > > QuerySet > > > > > > with a today method which uses the function he defined above. > > > > > > > self.filter(creation_date__range=today()) # __range is part of the > > > > > >djangofiltering syntax > > > > > > > Then he creates a custom Manager (EventManager) and assigns it to > > > > > > 'objects' in his model: > > > > > > > class Event(models.Model) > > > > > > #.... > > > > > > objects = EventManager() > > > > > > > So now when he calls Event.objects he is really calling an instance > > > > > > of > > > > > > the EventManager() > > > > > > > He does one more thing though.. All models have a default save > > > > > > method > > > > > > which is called explicitly to commit changes. He overrides the > > > > > > inherited default save method with this one: > > > > > > > def save(self, **kwargs): > > > > > > Event.objects.filter(latest=True, > > > > > > creator=self.creator).today().update(latest=False) > > > > > > super(Event, self).save(**kwargs) > > > > > > > So now whenever an Event object is saved, this code will execute > > > > > > regardless of where it happens because save is a model method. > > > > > > > I think I explained that correctly (possibly not well :) > > > > > > > What would be the best (or most DRY) way to do something like this > > > > > > in > > > > > > web2py? > > > > > > > Thanks again to all for indulging my questions... > > > > > > > On Jul 29, 1:51 pm, Fran <francisb...@googlemail.com> wrote: > > > > > > > > On Jul 29, 6:51 pm, __future__ <wrigh...@gmail.com> wrote: > > > > > > > > > So can I create a custom filter like the EventQuerySet in the > > > > > > > > example > > > > > > > > and then apply it in the controller? I assume I will have to > > > > > > > > use this > > > > > > > > anywhere an event might get an update? Can I use it with crud? > > > > > > > > I don't quite follow the example (I'm not familiar withDjango) but > > > > > > > what I think you're looking for is: > > > > > > > crud.settings.create_onvalidation = lambda form: > > > > > > > mycustomfilter(form) > > > > > > > > F --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py-users" 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 -~----------~----~----~----~------~----~------~--~---
