I'm not sure that metro_area_name is accurate either. I am allowing users to enter an actual address, not necessarily just a city name.
So, if somebody enters, "Spider House Cafe, 2908 Fruth St., Austin, TX," it will display that along with a Google Maps link to that address. If they enter nothing, it will display the metro area name if the user has set one. If neither a location for the event nor a metro area for the user are set then it displays nothing. Do you not like the idea of allowing users to enter an address for the location? If you do not like the way I have done this, I have an alternate idea that I could put together: 1. Add a drop-down menu to the edit/new view to select a metro area. The default selection would be the user's metro area (if it is set). 2. Use location only as an address (or nil). 3. Update the index view to display separate lines for metro area (if set) and location (if set). This leaves the door open to add a link to filter the view by metro area. This way there is no need to override the location field by calculating what is set for location. Let me know what you think... On Mon, Jul 6, 2009 at 9:50 AM, Bruno Bornsztein <[email protected] > wrote: > I think metro_area_name is probably a clearer name than evt_location (since > it's returning the metro name if available, or an empty string if none)Thanks! > Bruno > > > On Sun, Jul 5, 2009 at 12:17 PM, eksatx <[email protected]> wrote: > >> >> I think I found (and fixed) a bug. I noticed that event location was >> being used in the view, but it didn't actually show up. It turns out >> that the Event model is over-riding the database attribute for >> location by instead returning the metro area (which was nil in my test >> case). >> >> So, I fixed it so location returns the location field stored in the >> database and evt_location (suggest a better name?) returns the >> location or the metro area name if the location is empty (or an empty >> string if both are nil). >> >> While I was at it, I updated the view to include a link to map the >> location via Google. >> >> I'll send a pull request for this as soon as I get a chance to run >> tests. >> >> On Jul 2, 8:26 am, Bruno Bornsztein <[email protected]> >> wrote: >> > > The administrator can add, edit, and delete events. Events can have >> > > start/end times/dates, titles, and descriptions. These attributes are >> > > displayed in the Event list. In the add/edit views there is a field >> > > for Location, although I'm not sure how this is used -- it is not >> > > displayed anywhere that I noticed. >> > >> > Location is just a text field where people can enter something like >> > "Minneapolis" or "My House". It's not used in the views, but you can >> easily >> > add it if you need it. >> > >> > >> > >> > > 1. Is it only possible for administrators to add/edit/delete events? >> > > Can moderators and/or members? >> > >> > Currently just admins. >> > >> > >> > >> > > 2. How is the location attribute used? >> > >> > See above. >> > >> > >> > >> > > 3. The Event model has a user_id field -- how is this used? >> > >> > It's not used. But in some apps I subclass Event and I need the subclass >> to >> > have an owner (Bulletins, in TennisMetro, are a subclass of Event). >> > >> > >> > >> > > 4. The Event model has a metro_area_id field -- how is this used? >> > >> > Same as above; it's nice to be able to attache a metro area to a >> subclass of >> > Event. >> > >> > > 5. Is there any other functionality that exists out-of-the-box? >> > >> > Nope. >> > >> > >> > >> > > Some of this stuff may only be known to Bruno. Thoughts? >> > >> > > On Jun 29, 6:22 pm, Justin G <[email protected]> wrote: >> > > > Thanks Errol, I figured someone submitted this patch considering the >> > > > "applying diff" commit message. Once I get some code in decent >> shape >> > > > I'll post my branch to github. >> > >> > > > I like your duplicate event idea because I expect to have events >> that >> > > > don't follow a predictable schedule, but may occur at the same place >> > > > or time of day. >> > >> > > > Justin >> > >> > > > On Jun 24, 5:15 pm, eksatx <[email protected]> wrote: >> > >> > > > > Thanks for the shout-out (I submitted that as a patch to Bruno as >> I >> > > > > had not yet gotten the hang of github, pull requests, etc.). >> > >> > > > > I'm definitely interested in fleshing out the events >> functionality. >> > > > > The things you suggested have all crossed my mind. >> > >> > > > > Here's another one: a link for 'duplicate event' that would be >> helpful >> > > > > for events that repeat. A link like that would be much easier >> than >> > > > > "repeating event" functionality (which in my opinion often ends up >> > > > > either to simplistic to be useful or too complicated for users to >> > > > > understand). >> > >> > > > > I will pitch in and help with this as soon as I am done with my >> > > > > current project. I am currently fleshing out the private message >> > > > > stuff. It is so close to being done that it made sense to me to >> knock >> > > > > that out. I'll post a separate topic about that in a minute. >> > >> > > > > Anyhow, I'll keep this thread bookmarked and come back to it when >> I'm >> > > > > free. >> > >> > > > > Errol >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CommunityEngine" 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/communityengine?hl=en -~----------~----~----~----~------~----~------~--~---
