From: Róman J. <ro...@mo...> - 2012-04-16 00:33:03
|
Hi, I've been mailing with Johannes Raggam back and forth regarding the current plone.app.event implementation and how to model a use case like this: John, a plone user, creates multiple events which recur every month for two years. He subscribes himself to an RSS feed created by a topic. After 5 Months he can not distinguish the events anymore, as they all show the dates when the event was created, but not each recurrence start/end dates. We think it's better to discuss this on the mailing list, rather in private. As it currently looks, the DateRecurringIndex index is already providing a good search interface to search for recurring events. Perhaps a solution to address the use case would be to create occurrences as individual objects. My hope with that approach is to show occurrences in event listings as well as a separate view for an occurrence on a recurring event. Most of the search forms, result pages and topics should be able to deal with this approach gracefully. An occurrence object could/should look all the same as it's event, but obviously shows different start/end dates. One additional bonus perhaps is even, that individual changes can be stored. Questions from my side: * What would be the performance impact in comparison with the current implementation. I saw there seems to be a boundary for unlimited events. I also saw that Lennart tried to address this issue. If the discussion leads us to use individual objects for occurrences, I'm happy to create a first implementation on a branch. Thanks a lot for the current implementation and for all the work which went into it. Well done! Cheers, -- Róman Joost Mooball IT = Internet 13 Rowland Street Coorparoo, Brisbane QLD 4151 mob: +61 (4) 1455 3212 skype: mooballdotcom Tel: +61 (7) 3843 0516 Fax: +61 (7) 3843 2316 http://www.mooball.com |
From: Lennart R. <re...@gm...> - 2012-04-16 08:21:13
|
On Mon, Apr 16, 2012 at 02:04, Róman Joost <ro...@mo...> wrote: > John, a plone user, creates multiple events which recur every month > for two years. He subscribes himself to an RSS feed created by a > topic. RSS is not designed to handle events. So the answer is "don't do that". There would, once everything is implemented, be an RFC5545 (aka iCalendar) feed you can subscribe to. > After 5 Months he can not distinguish the events anymore, as > they all show the dates when the event was created, but not each > recurrence start/end dates. If they have the same title he wouldn't be able to distinguish from them immediattely. > a good search interface to search for recurring events. Perhaps a > solution to address the use case would be to create occurrences as > individual objects. Create what, more specifically, and how? Are you actually proposing create recurrence objects in the content space? That will become an unmanageable mess immediately, clutter the UI and slow everything down. Creating the events when you save the objects will take a very long time, and then you have to somehow keep the created events synchronized with what the recurrence rule is, which would amount to deleting and recreating all of them. The end result is that every time you modify a recurring event saving it would take a long time, in some cases minutes. And how would you deal with events with infinite recurrence? This is simply not a good idea. > Questions from my side: > > * What would be the performance impact in comparison with the > current implementation. A complete disaster. > I saw there seems to be a boundary for > unlimited events. I also saw that Lennart tried to address this > issue. Yeah, when I get time I'm replacing DateRecurringIndex with plone.app.eventindex in plone.app.event and friends, which doesn't have this problem. //Lennart |
From: Jens W. K. <je...@bl...> - 2012-04-16 09:00:42
|
On 2012-04-16 02:04, Róman Joost wrote: > Hi, > > I've been mailing with Johannes Raggam back and forth regarding the > current plone.app.event implementation and how to model a use case like > this: > > John, a plone user, creates multiple events which recur every month > for two years. He subscribes himself to an RSS feed created by a > topic. After 5 Months he can not distinguish the events anymore, as > they all show the dates when the event was created, but not each > recurrence start/end dates. So we need primary the information which distinct recurrence was adressed somewhere. > We think it's better to discuss this on the mailing list, rather in > private. +1 :) > As it currently looks, the DateRecurringIndex index is already providing > a good search interface to search for recurring events. Perhaps a > solution to address the use case would be to create occurrences as > individual objects. My hope with that approach is to show occurrences in > event listings as well as a separate view for an occurrence on a > recurring event. Most of the search forms, result pages and topics > should be able to deal with this approach gracefully. > > An occurrence object could/should look all the same as it's event, but > obviously shows different start/end dates. -1 We dont need real objects in ZODB. We do only need the information which occurrence was adressed, i.e. as an integer index. And with this information the addressed occurence can be calculated. > One additional bonus perhaps is even, that individual changes can be > stored. I think with the icalendar format this is already possible? CMIIW. > Questions from my side: > > * What would be the performance impact in comparison with the > current implementation. I saw there seems to be a boundary for > unlimited events. I also saw that Lennart tried to address this > issue. As said I dont think this is a good idea, performance will be bad too. Lennart proposes even to not create objects on catalog level but calculate them on the fly therefore. > If the discussion leads us to use individual objects for occurrences, > I'm happy to create a first implementation on a branch. > > Thanks a lot for the current implementation and for all the work which > went into it. Well done! If an event recurring daily 3 times gets a new method "ocurrence" returning a datetime by index:: >>> event.ocurrence(self, 0) datetime.datetime(2012, 4, 16, 10, 21, 34, 444035) >>> event.ocurrence(self, 1) datetime.datetime(2012, 4, 17, 10, 21, 34, 444035) >>> event.ocurrence(self, 2) datetime.datetime(2012, 4, 18, 10, 21, 34, 444035) >>> event.ocurrence(self, 3) IndexError: list index out of range This could be implemented by doing:: >>> def ocurrence(self, idx): ... return IRecurrence(obj).occurrences(range_start, ... range_end)[idx] The we could add a subpath or traverser to create IEvent implementing non persistent objects on-the-fly using the index, i.e.:: http://localhost:9090/Plone/myevent/++ocurrence++2 or:: http://localhost:9090/Plone/myevent/ocurrenceview/2 An now we can use this url inside the feed or at other places where we need some URL pointing to a distinct event. Anyway, thats the easy part. So we need this information at the catalog level too. Here it gets difficult, because we have only one metadata object for one event in the catalog - and it is very ok that way. But the way to just add the index to the metadata (which would be the most natural way and what people would expect) does not work therefore. Bad enough. But we may use the current API to get the index of a brain and create a utility function for this:: >>> from plone.app.event import base >>> base.get_ocurrence_index(brain) 2 This feels not that natural but would do it. Just as an idea my 0.02€ Jens -- Klein & Partner KG, member of BlueDynamics Alliance |
From: Róman J. <ro...@mo...> - 2012-04-16 22:16:19
|
Hi Jens, On Mon, Apr 16, 2012 at 11:00:21AM +0200, Jens W. Klein wrote: > On 2012-04-16 02:04, Róman Joost wrote: > > [...] > > An occurrence object could/should look all the same as it's event, but > > obviously shows different start/end dates. > > -1 We dont need real objects in ZODB. > > We do only need the information which occurrence was adressed, i.e. as > an integer index. And with this information the addressed occurence can > be calculated. Point taken. Initially I had similar thoughts, but saw that this might need changes of several views in Plone and it's content types. > If an event recurring daily 3 times gets a new method "ocurrence" > returning a datetime by index:: > [...] > > The we could add a subpath or traverser to create IEvent implementing > non persistent objects on-the-fly using the index, i.e.:: > [...] > > Anyway, thats the easy part. > > So we need this information at the catalog level too. > [...] does not work therefore. Bad enough. > I think either way would work: an index or a (start-) date of the occurence. Cheers, -- Róman Joost *RECENT PROJECTS* www.bullsmasters.com.au www.pancreaticcancer.net.au www.allanlanger.com.au www.uonservices.org.au www.asiapacificforum.net Mooball IT = Internet 13 Rowland Street Coorparoo, Brisbane QLD 4151 mob: +61 (4) 1455 3212 skype: mooballdotcom Tel: +61 (7) 3843 0516 Fax: +61 (7) 3843 2316 http://www.mooball.com |
From: Johannes R. <rag...@ad...> - 2012-04-16 09:46:25
Attachments:
signature.asc
|
hi all, On Mon, 2012-04-16 at 10:04 +1000, Róman Joost wrote: > Hi, > > I've been mailing with Johannes Raggam back and forth regarding the > current plone.app.event implementation and how to model a use case like > this: > > John, a plone user, creates multiple events which recur every month > for two years. He subscribes himself to an RSS feed created by a > topic. After 5 Months he can not distinguish the events anymore, as > they all show the dates when the event was created, but not each > recurrence start/end dates. as lennart pointed out, i also do not think that storing each occurrence as an individual object would be the way to go. actually i like the idea of having a custom traverser to access each occurrence individually. my answer to this issue in the discussion with róman was, that the usecase can be solved from an UI viewpoint via different views: the calendar portlet already displays each occurrence of a recurring event separately under it's date (using base.get_events_by_date). but if you access the event detail view, you just get a list of all occurrences which makes it hard to find those of interest (especially if there are a lot of occurrences which are batched over different pages). maybe we can solve that like so: * passing a query parameter to the detail view or using a custom traverser with the occurrence id (as jens proposed). then this date is shown most prominent. * if no query parameter/custom traverser is used, show the most recent date most prominent. the same applies for other event views, e.g. in folder listings or the like. > One additional bonus perhaps is even, that individual changes can be > stored. having different contents for each occurrence is a common usecase. e.g. recurring theater plays in my hometown often have different start/end times. maybe even different locations. exhibitions often have special openings and closings. this is supported by RFC5545/icalendar standard - but not by plone.app.event at the moment. i think we could annotate individual recurrence information (custom text, different start/end times) on the event object with the recurrence id (a property, which is defined by the RFC5545) as key. but implementing this is out of scope for me at the moment. i'm happy about any contributions! cheers, hannes -- programmatic web development di(fh) johannes raggam / thet python plone zope development mail: of...@pr... web: http://programmatic.pro http://bluedynamics.com |
From: Róman J. <ro...@mo...> - 2012-04-16 22:05:31
|
Hi Lennart, On Mon, Apr 16, 2012 at 10:20:42AM +0200, Lennart Regebro wrote: > On Mon, Apr 16, 2012 at 02:04, Róman Joost <ro...@mo...> wrote: > > John, a plone user, creates multiple events which recur every month > > for two years. He subscribes himself to an RSS feed created by a > > topic. > > RSS is not designed to handle events. So the answer is "don't do that". > There would, once everything is implemented, be an RFC5545 (aka > iCalendar) feed you can subscribe to. > Yes - already figured this one out. But you know users and their expectations ... > > After 5 Months he can not distinguish the events anymore, as > > they all show the dates when the event was created, but not each > > recurrence start/end dates. > > If they have the same title he wouldn't be able to distinguish from > them immediattely. > Good point. > > a good search interface to search for recurring events. Perhaps a > > solution to address the use case would be to create occurrences as > > individual objects. > > Create what, more specifically, and how? > > Are you actually proposing create recurrence objects in the content > space? > [...] > > And how would you deal with events with infinite recurrence? > > This is simply not a good idea. I was worried that will happen. Ok, forget the idea. > Yeah, when I get time I'm replacing DateRecurringIndex with > plone.app.eventindex in plone.app.event and friends, which doesn't > have this problem. Perhaps I could help with this too, if it's just replacing the start/end indexes? Cheers, -- Róman Joost *RECENT PROJECTS* www.bullsmasters.com.au www.pancreaticcancer.net.au www.allanlanger.com.au www.uonservices.org.au www.asiapacificforum.net Mooball IT = Internet 13 Rowland Street Coorparoo, Brisbane QLD 4151 mob: +61 (4) 1455 3212 skype: mooballdotcom Tel: +61 (7) 3843 0516 Fax: +61 (7) 3843 2316 http://www.mooball.com |
From: Lennart R. <re...@gm...> - 2012-04-17 06:12:41
|
On Tue, Apr 17, 2012 at 00:07, Róman Joost <ro...@mo...> wrote: > Hi Lennart, > > On Mon, Apr 16, 2012 at 10:20:42AM +0200, Lennart Regebro wrote: >> On Mon, Apr 16, 2012 at 02:04, Róman Joost <ro...@mo...> wrote: >> > John, a plone user, creates multiple events which recur every month >> > for two years. He subscribes himself to an RSS feed created by a >> > topic. >> >> RSS is not designed to handle events. So the answer is "don't do that". >> There would, once everything is implemented, be an RFC5545 (aka >> iCalendar) feed you can subscribe to. >> > Yes - already figured this one out. But you know users and their > expectations ... Yeah, they need to be educated sometimes. It's not easy. > Perhaps I could help with this too, if it's just replacing the start/end > indexes? The replacing is easy. Making sure it still works afterwards may not be. You are welcome to try. //Lennart |
From: Róman J. <ro...@mo...> - 2012-04-16 22:23:57
|
Hi Johannes, On Mon, Apr 16, 2012 at 11:46:13AM +0200, Johannes Raggam wrote: > [...] > the calendar portlet already displays each occurrence of a recurring > event separately under it's date (using base.get_events_by_date). but if > you access the event detail view, you just get a list of all occurrences > which makes it hard to find those of interest (especially if there are a > lot of occurrences which are batched over different pages). maybe we can > solve that like so: > > * passing a query parameter to the detail view or using a custom > traverser with the occurrence id (as jens proposed). then this date > is shown most prominent. > > * if no query parameter/custom traverser is used, show the most recent > date most prominent. > > the same applies for other event views, e.g. in folder listings or the > like. Happy with that. Cheers! > > One additional bonus perhaps is even, that individual changes can be > > stored. > > having different contents for each occurrence is a common usecase. e.g. > recurring theater plays in my hometown often have different start/end > times. maybe even different locations. exhibitions often have special > openings and closings. > > this is supported by RFC5545/icalendar standard - but not by > plone.app.event at the moment. > > i think we could annotate individual recurrence information (custom > text, different start/end times) on the event object with the recurrence > id (a property, which is defined by the RFC5545) as key. AAaah... good idea! Let me see what I can do. I'd be happy to focus on the traversing after talking to my boss as he acquired the funding. What would be the best way to share this code? I just continue on my fork with the implementation and issue pull requests or is there anything better? Cheers, -- Róman Joost *RECENT PROJECTS* www.bullsmasters.com.au www.pancreaticcancer.net.au www.allanlanger.com.au www.uonservices.org.au www.asiapacificforum.net Mooball IT = Internet 13 Rowland Street Coorparoo, Brisbane QLD 4151 mob: +61 (4) 1455 3212 skype: mooballdotcom Tel: +61 (7) 3843 0516 Fax: +61 (7) 3843 2316 http://www.mooball.com |
From: beams <to...@mo...> - 2012-04-17 06:41:02
|
Jens W. klein-2 wrote > > ... > This could be implemented by doing:: > > >>> def ocurrence(self, idx): > ... return IRecurrence(obj).occurrences(range_start, > ... range_end)[idx] > > > The we could add a subpath or traverser to create IEvent implementing > non persistent objects on-the-fly using the index, i.e.:: > > http://localhost:9090/Plone/myevent/++ocurrence++2 > > or:: > > http://localhost:9090/Plone/myevent/ocurrenceview/2 > > An now we can use this url inside the feed or at other places where we > need some URL pointing to a distinct event. > If we decide that you will only ever recur on a daily basis then surely the occurrence could be represented in the URL as a date i.e. http://localhost:9090/Plone/myevent/ocurrenceview/2008-04-18 That would be much nicer for viewers, easier to interpret and guess. Better still http://localhost:9090/Plone/myevent/2008-04-18 Jens W. klein-2 wrote > > Anyway, thats the easy part. > > So we need this information at the catalog level too. Here it gets > difficult, because we have only one metadata object for one event in the > catalog - and it is very ok that way. But the way to just add the index > to the metadata (which would be the most natural way and what people > would expect) does not work therefore. Bad enough. > > But we may use the current API to get the index of a brain and create a > utility function for this:: > > >>> from plone.app.event import base > >>> base.get_ocurrence_index(brain) > 2 > > This feels not that natural but would do it. > > Just as an idea my 0.02€ > > Jens > OK provided we have a brain for each occurrence then I think this will work, but it seems to me that you then face the task of building this logic into event listings, collections, search results and any other query that returns events. Thats an unfortunate task. I noticed posts about 2 other things that Id like to comment on. One is unlimited occurrences. As a practical person I do question the value of worrying about this. Its lovely to achieve if possible but if it poses practical problems then it seems it could turn into a lot of effort for a very rare case. I cant even imagine a case where it would not be practical to put some kind of end limit on a recurring event. The second is variations of an events start time/end time or other properties. Again, Id take the pragmatic argument that if these properties vary then its not a recurring event, its a series of different events. Certainly on Google Apps, if you change anything about an event then it breaks the series and I think that would be generally accepted. -- View this message in context: http://plone.293351.n2.nabble.com/Separate-occurrence-objects-for-plone-app-event-tp7468884p7472545.html Sent from the Core Developers mailing list archive at Nabble.com. |
From: Róman J. <ro...@mo...> - 2012-04-18 01:31:51
|
Hi Jens, On Mon, Apr 16, 2012 at 11:00:21AM +0200, Jens W. Klein wrote: > [...] > If an event recurring daily 3 times gets a new method "ocurrence" > returning a datetime by index:: > > >>> event.ocurrence(self, 0) > datetime.datetime(2012, 4, 16, 10, 21, 34, 444035) > > >>> event.ocurrence(self, 1) > datetime.datetime(2012, 4, 17, 10, 21, 34, 444035) > > >>> event.ocurrence(self, 2) > datetime.datetime(2012, 4, 18, 10, 21, 34, 444035) > > >>> event.ocurrence(self, 3) > IndexError: list index out of range > > This could be implemented by doing:: > > >>> def ocurrence(self, idx): > ... return IRecurrence(obj).occurrences(range_start, > ... range_end)[idx] > > > The we could add a subpath or traverser to create IEvent implementing > non persistent objects on-the-fly using the index, i.e.:: > [...] > > But we may use the current API to get the index of a brain and create a > utility function for this:: > > >>> from plone.app.event import base > >>> base.get_ocurrence_index(brain) > 2 A catalog query returns the brain for the event and not for each occurrence. That's what makes calculating now each occurences on the fly in a view a bit tricky, because you loose all benefits of the catalogs sorting mechanism. Although in a discussion with Tom, he pointed out an interesting point we forget with this solution: sorting. Doing a search for recurring events will return each event. Afterwards I'll have to re-sort/re-compile the search result by iterating over each event to assemble the occurences which should be visible in the search result as well. Even if I have the brain, I will need access to the object to perform this task. Where am I missing something? Perhaps the API already returns the occurences correctly sorted ... Cheers, -- Róman Joost *RECENT PROJECTS* www.bullsmasters.com.au www.pancreaticcancer.net.au www.allanlanger.com.au www.uonservices.org.au www.asiapacificforum.net Mooball IT = Internet 13 Rowland Street Coorparoo, Brisbane QLD 4151 mob: +61 (4) 1455 3212 skype: mooballdotcom Tel: +61 (7) 3843 0516 Fax: +61 (7) 3843 2316 http://www.mooball.com |
From: Lennart R. <re...@gm...> - 2012-04-18 05:33:30
|
On Wed, Apr 18, 2012 at 03:33, Róman Joost <ro...@mo...> wrote: > A catalog query returns the brain for the event and not for each > occurrence. Yup. The catalog is for searching for objects. Returning multiple brains for the same object would in most cases be confusing. A typical usecase is to search for all events during a time period. If a search in a search form was to search for all events in March, and you get 31 copies of one event, that's probably not what you want. Also, since it's the same object, you'll have the same start and end date on all of the objects anyway, so it doesn't really help you. You want a list of all occurrences during the time period, and that's a different kind of search. It's necessary and highly useful, but I'm not convinced it should be an integral part of the catalog. //Lennart |
From: Tom C. <to...@mo...> - 2012-04-18 22:21:27
|
Lennart, On Thu, Apr 19, 2012 at 07:51, Lennart Regebro <re...@gm...> wrote: > On Wed, Apr 18, 2012 at 19:08, Tom Cameron <to...@mo...> wrote: > > That is a major divergence from how Plone currently works and I tend to > > disagree. One of the very nicest features of Plone is that you have a > single > > central catalog that indexes everything and any query is capable of > finding > > any object. You seem to be suggesting a move away from this model > > Nowhere did I say that Event should not be indexed in the catalog or > searchable in the standard search. Doing so would indeed be a very bad > idea. Which is why I didn't suggest it. :-) > > What I did say is that the standard search should *not* return one > entry for each occurrence, as that would make that search almost > unusable in the case of you having a recurring event in the search > results. For the cases where you do want this, ie when you are > searching for *only* events, withing a specific time limit, then it > makes sense. But that is another search than the generic search. The > generic search should *not* behave like that. > > > What if you have a weekly card night for 10 years and on the 9th year you > > search for upcoming events, would you expect to see one item in the > results > > that links back to the original event 9 years ago? > > Yes. > > > surely not > > Why not? The event says "Weekly card night". That's what you are > looking for, isn't it? Why would you not expect it to show up? Note > that your suggestion is that we show 520 "Weekly card nights", most of > which has passed already. Is *that* useful to you? > I said I was searching for "upcoming events" so I would expect only the future occurrences to show up. That would be what I expect and that would be what I would get if I had separate items returned for each occurrence. I would never ever expect a past event to show up in a search for future events. > > are other events in your result set how do you sort them if you don't > show > > each occurrence? > > Sort on what? You are talking about the *generic Plone search* here, > remember that. The only date it sorts on are publication dates, not > event dates. > Actually in this case I was talking about "upcoming" events, like you may get in a collection or a query that specified a date range. > > does your single result come first or last or between the > > others > > No. You are again constantly talking about searching for events and > events only. I'm trying to explain to you that this is a very > different use case from the standard generic Plone search. They are > not good matches, and you can not make them into one search without > limiting usability. Lennart, I know that there are two different use cases - searching without a date range, and searching with a date range, but I can perform both with the standard Plone search and I can perform both with a collection and as it currently stands I have no way of varying how it handles occurrences based on that search criteria. Im talking about having it one way or the other and if I am forced to choose one then I would always want to get a result for each occurrence. Anyway this discussion is becoming more philosophical about how we should handle occurrences but I think we generally agree that if you search with a date in mind you would expect to see occurrences and if you don't search with a date then it may be better to show one result for a series. But that still leaves me unsure of how any of this is going to be implemented and how I can work with the community to help. My use case is very simple. Right now my client manually entered 52 events into Plone for a weekly event that happens all year. They manually enter 12 entries for monthly events and so on. They are perfectly happy with the search results, they are perfectly happy with the fact that they get multiple results for their searches. What they hate doing is the manual effort for entering the objects. They want us to automate this some way to reduce the effort - they have no requirement at all to change how the searches behave or how the results are shown. In fact they would be upset if we only returned one item for a series. This is a real world case - a real client with real money to pay. Due to timing constraints I expect we will go ahead with some process of creating objects with a limited number of occurrences. Hopefully we may be able to contribute something of value back to the community. And a big thank you to everyone who has chipped in - at the very least I think its been a good healthy conversation and some ideas coming out of it. Tom |
From: Róman J. <ro...@mo...> - 2012-04-18 23:15:11
|
Hi, On Thu, Apr 19, 2012 at 08:20:56AM +1000, Tom Cameron wrote: > [...] > Due to timing constraints I expect we will go ahead with some process of > creating objects with a limited number of occurrences. Hopefully we may be > able to contribute something of value back to the community. No matter what we end up implementing, I'm very curious on how to solve this. I've thought about this over a few nights. I think there is almost no difference between creating occurence objects which can be indexed and 'real' events (let's take the dexterity CT - they're lighter). If we do this and what I understood from Lennart is, that changing a recurrence rule, will basically mean an I/O bound performance impact as I need to update/delete *n* persistent objects from the database, not to mention the redundant data which is created and indexed. Calculating the occurences on the fly means, that it's only a CPU bound operation. I can also see, that recurrence and therefore view implementation heavily depends on the use case. As Lennart put it when searching for events: It's not what users want even though in some cases they might expect it. I also had the idea Jens and Laurence had by changing how the brains are created. This would sort of get us results for non-persistent objects, but would potentially change the purpose of the catalog. What does it leave us with? Perhaps back to the drawing board? Cheers, -- Róman Joost *RECENT PROJECTS* www.bullsmasters.com.au www.pancreaticcancer.net.au www.allanlanger.com.au www.uonservices.org.au www.asiapacificforum.net Mooball IT = Internet 13 Rowland Street Coorparoo, Brisbane QLD 4151 mob: +61 (4) 1455 3212 skype: mooballdotcom Tel: +61 (7) 3843 0516 Fax: +61 (7) 3843 2316 http://www.mooball.com |
From: Tom C. <to...@mo...> - 2012-04-18 23:41:21
|
Roman On Thu, Apr 19, 2012 at 09:16, Róman Joost <ro...@mo...> wrote: > Hi, > > On Thu, Apr 19, 2012 at 08:20:56AM +1000, Tom Cameron wrote: > > [...] > > Due to timing constraints I expect we will go ahead with some process of > > creating objects with a limited number of occurrences. Hopefully we may > be > > able to contribute something of value back to the community. > No matter what we end up implementing, I'm very curious on how to solve > this. I've thought about this over a few nights. I think there is almost > no difference between creating occurence objects which can be indexed > and 'real' events (let's take the dexterity CT - they're lighter). > If we do this and what I understood from Lennart is, that changing a > recurrence rule, will basically mean an I/O bound performance impact as > I need to update/delete *n* persistent objects from the database, not to > mention the redundant data which is created and indexed. Surely this will be no worse than cut-past a folder with n objects in it. In that case the reindex has to delete n items from the catalog and add n back after reindexing. That is a standard use-case that exist in Plone today and nobody has ever complained. Tom |
From: Laurence R. <l...@lr...> - 2012-04-18 23:49:05
|
On 19 April 2012 00:40, Tom Cameron <to...@mo...> wrote: > Roman > > On Thu, Apr 19, 2012 at 09:16, Róman Joost <ro...@mo...> wrote: >> >> Hi, >> >> On Thu, Apr 19, 2012 at 08:20:56AM +1000, Tom Cameron wrote: >> > [...] >> > Due to timing constraints I expect we will go ahead with some process of >> > creating objects with a limited number of occurrences. Hopefully we may >> > be >> > able to contribute something of value back to the community. >> No matter what we end up implementing, I'm very curious on how to solve >> this. I've thought about this over a few nights. I think there is almost >> no difference between creating occurence objects which can be indexed >> and 'real' events (let's take the dexterity CT - they're lighter). >> If we do this and what I understood from Lennart is, that changing a >> recurrence rule, will basically mean an I/O bound performance impact as >> I need to update/delete *n* persistent objects from the database, not to >> mention the redundant data which is created and indexed. > > > Surely this will be no worse than cut-past a folder with n objects in it. In > that case the reindex has to delete n items from the catalog and add n back > after reindexing. That is a standard use-case that exist in Plone today and > nobody has ever complained. Those with larger sites (hundreds of thousands of catalogued content objects) complain frequently. The problem is an artefact of a long ago fixed limitation in ZODB that meant cyclic object references couldn't be used. Hopefully it will be addressed in Zope4 with the addition of ZTK style __parent__ pointers allowing us to index objects directly in the catalog rather than by their paths and we won't have to completely unindex and reindex a subtree on a move but simply update the path index. Laurence |
From: Yuri <yu...@al...> - 2012-04-19 06:11:03
|
Il 19/04/2012 01:48, Laurence Rowe ha scritto: > Those with larger sites (hundreds of thousands of catalogued content > objects) complain frequently. The problem is an artefact of a long ago > fixed limitation in ZODB that meant cyclic object references couldn't > be used. Hopefully it will be addressed in Zope4 From Five (2+3) to Nine (2+3+4) :-) |
From: Johannes R. <rag...@ad...> - 2012-04-19 00:19:38
Attachments:
signature.asc
|
On Thu, 2012-04-19 at 02:16 +0200, Johannes Raggam wrote: > On Thu, 2012-04-19 at 00:48 +0100, Laurence Rowe wrote: > > > Those with larger sites (hundreds of thousands of catalogued content > > objects) complain frequently. The problem is an artefact of a long ago > > fixed limitation in ZODB that meant cyclic object references couldn't > > be used. Hopefully it will be addressed in Zope4 with the addition of > > ZTK style __parent__ pointers allowing us to index objects directly in > > the catalog rather than by their paths and we won't have to completely > > unindex and reindex a subtree on a move but simply update the path > > index. > > oh, that would be nice... -- programmatic web development di(fh) johannes raggam / thet python plone zope development mail: of...@pr... web: http://programmatic.pro http://bluedynamics.com |
From: Tom C. <to...@mo...> - 2012-04-18 06:20:08
|
Lennart On Wed, Apr 18, 2012 at 15:33, Lennart Regebro <re...@gm...> wrote: > On Wed, Apr 18, 2012 at 03:33, Róman Joost <ro...@mo...> wrote: > > A catalog query returns the brain for the event and not for each > > occurrence. > > Yup. The catalog is for searching for objects. Returning multiple > brains for the same object would in most cases be confusing. A typical > usecase is to search for all events during a time period. If a search > in a search form was to search for all events in March, and you get 31 > copies of one event, that's probably not what you want. Also, since > it's the same object, you'll have the same start and end date on all > of the objects anyway, so it doesn't really help you. > > You want a list of all occurrences during the time period, and that's > a different kind of search. It's necessary and highly useful, but I'm > not convinced it should be an integral part of the catalog. > > //Lennart > > So this brings us around in circles. We need the separate occurrences. If we do a search for events in march and it returns back say 10 objects, of which 5 may be recurring events, we then need to interrogate each of these 5 events again to find their occurrences, then merge the list of occurrences of each of those events into one list - re-sort them and then we can display our results. This means multiple queries and sorting all at the view level which seems crazy to me. All of this leads me to the conclusion that we DO need separate objects for each occurrence - this would solve all these issues and remove the need for crazy re-querying of the recurring event objects. I know that creating objects for the occurrences may cause some kind of performance hit when editing, but I really want to know is that actually worse that this situation we are heading towards at the moment? Tom |
From: Jens W. K. <je...@bl...> - 2012-04-18 08:22:58
|
On 2012-04-18 07:49, Tom Cameron wrote: > Lennart > > On Wed, Apr 18, 2012 at 15:33, Lennart Regebro > <re...@gm... > <mailto:re...@gm...>> wrote: > > On Wed, Apr 18, 2012 at 03:33, Róman Joost > <ro...@mo... > <mailto:ro...@mo...>> wrote: > > A catalog query returns the brain for the event and not for each > > occurrence. > > Yup. The catalog is for searching for objects. Returning multiple > brains for the same object would in most cases be confusing. A typical > usecase is to search for all events during a time period. If a search > in a search form was to search for all events in March, and you get 31 > copies of one event, that's probably not what you want. Also, since > it's the same object, you'll have the same start and end date on all > of the objects anyway, so it doesn't really help you. > > You want a list of all occurrences during the time period, and that's > a different kind of search. It's necessary and highly useful, but I'm > not convinced it should be an integral part of the catalog. > > //Lennart > > > So this brings us around in circles. We need the separate occurrences. As said, we have them already on the logical level. We just need a way to adress them. > If we do a search for events in march and it returns back say 10 > objects, of which 5 may be recurring events, we then need to interrogate > each of these 5 events again to find their occurrences, then merge the > list of occurrences of each of those events into one list - re-sort them > and then we can display our results. This means multiple queries and > sorting all at the view level which seems crazy to me. We may improve the way we do this and add tools to libs such as plone.app.event (or plone.event) to get the work off the programmer. > All of this leads me to the conclusion that we DO need separate objects > for each occurrence - this would solve all these issues and remove the > need for crazy re-querying of the recurring event objects. I know that And I believe this is wrong and must result in very bad performance. > creating objects for the occurrences may cause some kind of performance > hit when editing, but I really want to know is that actually worse that > this situation we are heading towards at the moment? Well, its the simplest solution to just replicate objects, but its not an enterprise solution and will result in problems at some point.. Jens -- Klein & Partner KG, member of BlueDynamics Alliance |
From: Lennart R. <re...@gm...> - 2012-04-18 06:59:26
|
On Wed, Apr 18, 2012 at 07:49, Tom Cameron <to...@mo...> wrote: > So this brings us around in circles. Absolutely not. > We need the separate occurrences. If we > do a search for events in march and it returns back say 10 objects, of which > 5 may be recurring events, we then need to interrogate each of these 5 > events again to find their occurrences, then merge the list of occurrences > of each of those events into one list - re-sort them and then we can display > our results. This means multiple queries and sorting all at the view level > which seems crazy to me. Telling us that the catalog is the wrong place to do that sort of search. It's not designed to be a calendar. Maybe it can be designed to be it, but I'm still not convinced the catalog is the right place. > All of this leads me to the conclusion that we DO need separate objects for > each occurrence That just causes even more and worse problems. So it's the wrong conclusion. > but I really want to know is that actually worse that this > situation we are heading towards at the moment? Yes. And we are not "heading" to that situation, it is how it always have been. It will be more obvious when recurring events is a part of the core, but the situation has always been there. It is great that more people want to help to improve the calendaring support in Plone, but separate objects for each occurrence is not an improvement. //Lennart |
From: Tom C. <to...@mo...> - 2012-04-18 07:40:14
|
Lennart On Wed, Apr 18, 2012 at 16:58, Lennart Regebro <re...@gm...> wrote: > On Wed, Apr 18, 2012 at 07:49, Tom Cameron <to...@mo...> wrote: > > So this brings us around in circles. > > > We need the separate occurrences. If we > > do a search for events in march and it returns back say 10 objects, of > which > > 5 may be recurring events, we then need to interrogate each of these 5 > > events again to find their occurrences, then merge the list of > occurrences > > of each of those events into one list - re-sort them and then we can > display > > our results. This means multiple queries and sorting all at the view > level > > which seems crazy to me. > > Telling us that the catalog is the wrong place to do that sort of > search. It's not designed to be a calendar. Maybe it can be designed > to be it, but I'm still not convinced the catalog is the right place. > > > All of this leads me to the conclusion that we DO need separate objects > for > > each occurrence > Absolutely not. > > > That just causes even more and worse problems. So it's the wrong > conclusion. > > > but I really want to know is that actually worse that this > > situation we are heading towards at the moment? > > Yes. And we are not "heading" to that situation, it is how it always > have been. It will be more obvious when recurring events is a part of > the core, but the situation has always been there. > > It is great that more people want to help to improve the calendaring > support in Plone, but separate objects for each occurrence is not an > improvement. > > //Lennart > I really value your input but Im not sure this is getting me anywhere. My situation is that I have a client that needs recurring events happening and working in the next 2-3 weeks. Regardless of what you are doing we will be building a solution for them in that time. Ive really been hoping to collaborate with the community and contribute our efforts back, but to do that I need to understand exactly how you propose to solve these occurrence issues and then we can make sure that our efforts are in the same direction as yours and that our work is useful to the community. You state "It will be more obvious when recurring events is a part of the core," but I need that to be obvious to me now, we cant wait any longer. So what Im asking is "how do you propose to handle the display of each occurrence? How do we find them? and sort them? Can you give us any direction at all that would allow us to build this now or are we just going to have to go it alone and build our own custom solution (which I would really hate to do but commercially I may be forced to do)? Tom -- *Tom Cameron* Technical Director *Mooball IT* 13 Rowland Street Coorparoo, Brisbane QLD 4151 mob: +61 (4) 1455 3212 skype: mooballdotcom Tel: +61 (7) 3843 0516 Fax: +61 (7) 3843 2316 http://www.mooball.com <http://www.mooball.com/> *RECENT PROJECTS* www.bullsmasters.com.au www.pancreaticcancer.net.au www.allanlanger.com.au www.uonservices.org.au www.asiapacificforum.net *WHAT'S NEW* - Mooball IT is now an authorised *Google Apps*<http://www.google.com/apps/intl/en/business/messaging.html> Reseller - *watch the video <http://www.youtube.com/watch?v=9JJDugn4RoQ>* <http://www.youtube.com/watch?v=kJT3pagjd8s>*- Google Apps now has rich text email signatures with images * *- Plone 4* is now here upgrade to get new features and faster page loads. - Register and renew your domain at *Mooball Domains*<http://domains.mooball.com/> * * *WEB AGENCY SPECIALISING IN PLONE DEVELOPMENT AND HOSTING* Plone CMS | Web Apps | Discount Domains | Web Hosting | Google Apps Email disclaimer <http://www.mooball.com/email_disclaimer> |
From: Lennart R. <re...@gm...> - 2012-04-18 12:10:30
|
On Wed, Apr 18, 2012 at 09:09, Tom Cameron <to...@mo...> wrote: > My situation is that I have a client that needs recurring events happening > and working in the next 2-3 weeks. > Well, define "working". :-) I've been working on improving the state of calendaring for Plone since 2007. The only one that has been willing to invest money in that during this time is Nate Aune. From that situation, expecting that it now suddenly will be finished in 2-3 weeks is unrealistic. Calendaring is not an easy problem, it is a very large set of difficult ones. As such, I hope that your definition of "working" is only a subset of what is needed for a complete solution. That said, a complete solution isn't *that* far away, we are still hoping (possibly overoptimistically) that it will be done for Plone 4.3, which I think means at the end of the year or so. If you want anything of this faster, you'll have to put in significant manpower, or monetary resources. Most if it is done and working as of today. But not everything. Regardless of what you are doing we will be building a solution for them in > that time. Ive really been hoping to collaborate with the community and > contribute our efforts back, but to do that I need to understand exactly > how you propose to solve these occurrence issues > What issues? The only actual issue mentioned here so far is that RSS doesn't work for recurring events. It's correct, it does not work, and will never work. RSS is not made for events and calendaring. What you need is iCalendar. I don't think there is an iCalendar solution for recurring events yet either, but that you could build in 2-3 weeks realistically, no problemo. and then we can make sure that our efforts are in the same direction as > yours and that our work is useful to the community. > The you need to join in the plone.app.event effort, managed by Johannes Raggam is leading, and see what you can do there to help finish it. > You state "It will be more obvious when recurring events is a part of the > core," but I need that to be obvious to me now, we cant wait any longer. > If you and your customer have waited for a long time, I think it would have been good if you had made the community aware of this, and maybe see if the customer was willing to actually fund the development of this functionality, instead of just expecting it to be done by magic. > So what Im asking is "how do you propose to handle the display of each > occurrence? How do we find them? and sort them? > All of these are open-ended questions where it is not obvious what your requirements are, or why you feel the current situation is problematic. As such it is impossible to answer in a useful manner. Can you give us any direction at all that would allow us to build this now > or are we just going to have to go it alone and build our own custom > solution (which I would really hate to do but commercially I may > be forced to do)? > I can promise you that building your own solution will take much longer than finishing plone.app.event. This discussion is not constructive. Roman and you came here with a solution for a problem that is not really a problem (that RSS can't handle recurring events). This solution will create more problems than it solves. A real usable solution (use iCalendar) was proposed. Now you seem angry that we don't want to adopt your non-solution to your non-problem. I really don't see why this is so. Have you taken a look at plone.app.event in it's current state? Do you have any concrete issues with it that you need solved before the 2-3 week deadline? Which are those? How do you propose to solve them? //Lennart |
From: Tom C. <to...@mo...> - 2012-04-18 13:19:36
|
Lennart, First of all, Im so sorry if any previous messages sound rude. Im just struggling to get our questions across. On Wed, Apr 18, 2012 at 22:09, Lennart Regebro <re...@gm...> wrote: > On Wed, Apr 18, 2012 at 09:09, Tom Cameron <to...@mo...> wrote: > >> My situation is that I have a client that needs recurring events >> happening and working in the next 2-3 weeks. >> > > Well, define "working". :-) > > I've been working on improving the state of calendaring for Plone since > 2007. The only one that has been willing to invest money in that during > this time is Nate Aune. From that situation, expecting that it now suddenly > will be finished in 2-3 weeks is unrealistic. Calendaring is not an easy > problem, it is a very large set of difficult ones. > > As such, I hope that your definition of "working" is only a subset of what > is needed for a complete solution. > > That said, a complete solution isn't *that* far away, we are still hoping > (possibly overoptimistically) that it will be done for Plone 4.3, which I > think means at the end of the year or so. If you want anything of this > faster, you'll have to put in significant manpower, or monetary resources. > > Most if it is done and working as of today. But not everything. > > Regardless of what you are doing we will be building a solution for them >> in that time. Ive really been hoping to collaborate with the community and >> contribute our efforts back, but to do that I need to understand exactly >> how you propose to solve these occurrence issues >> > > What issues? The only actual issue mentioned here so far is that RSS > doesn't work for recurring events. It's correct, it does not work, and will > never work. RSS is not made for events and calendaring. What you need is > iCalendar. I don't think there is an iCalendar solution for recurring > events yet either, but that you could build in 2-3 weeks realistically, no > problemo. > Ill define working and answer this in one go. Basically we need two things that the current product does not offer: 1. We need to be able to view each individual occurrence on its own. This is not terribly difficult, as everyone has suggested this could be achieved via some kind of URL query string or path. 2. We need any search to return each individual occurrence as a separate result. e.g. If I search for all events in May and there is a weekly recurring meeting I need to get 4 separate results each of which links to its own occurrence view. If I search Plone for all objects tagged 'blah' then I want to find all objects that match that keyword including all occurrences of any event that matches. This needs to work for general site searches and for collections, portlets, basically any place that you would naturally expect a search for events to work. Our highest priority would be collections because they are used to show things like 'upcoming events', but the main site search is also very important. You and I know that a recurring event is only one object in the database, but any site visitor would naturally expect each occurrence to behave as separate 'objects' anywhere you find events. Currently the only place this works is the calendar, except that it does not link to the occurrences. In addition Ill state what we don't need: 1. We don't need infinite occurrences 2. We don't need occurrences to vary in any way other than the date, any variation in other properties such as description or time can be simply considered as a single event not part of the series 3. We actually don't need the ability to add or remove occurrences that are not part of the regular series. Though I see you have this feature already so that is handy. > and then we can make sure that our efforts are in the same direction as >> yours and that our work is useful to the community. >> > > The you need to join in the plone.app.event effort, managed by Johannes > Raggam is leading, and see what you can do there to help finish it. > > >> You state "It will be more obvious when recurring events is a part of the >> core," but I need that to be obvious to me now, we cant wait any longer. >> > > If you and your customer have waited for a long time, I think it would > have been good if you had made the community aware of this, and maybe see > if the customer was willing to actually fund the development of this > functionality, instead of just expecting it to be done by magic. > The client only made us aware of their requirement about 4 weeks ago. And we only stumbled across this project about 2 weeks ago, so we had no way of informing anyone earlier. We are quite prepared to develop a solution for the client independently and its only once we found this project that we have started to investigate it and find out how it works and what its limitations it has (in relation to our client's requirements). > So what Im asking is "how do you propose to handle the display of each >> occurrence? How do we find them? and sort them? >> > > All of these are open-ended questions where it is not obvious what your > requirements are, or why you feel the current situation is problematic. As > such it is impossible to answer in a useful manner. > > Can you give us any direction at all that would allow us to build this now >> or are we just going to have to go it alone and build our own custom >> solution (which I would really hate to do but commercially I may >> be forced to do)? >> > > I can promise you that building your own solution will take much longer > than finishing plone.app.event. > > This discussion is not constructive. Roman and you came here with a > solution for a problem that is not really a problem (that RSS can't handle > recurring events). This solution will create more problems than it solves. > A real usable solution (use iCalendar) was proposed. Now you seem angry > that we don't want to adopt your non-solution to your non-problem. I really > don't see why this is so. > Im sorry if it sounds that way, Im really just trying to be constructive. Im not sure why Roman mentioned RSS at all, that is not what we are looking for, I mentioned it as an example of a generic query that you would naturally expect to return each occurrence, it is not a specific requirement. My 2 points above more clearly indicate what we need for the client. > Have you taken a look at plone.app.event in it's current state? > Yes, we have been looking very closely at the code over the past 2 weeks and believe we understand how it works clearly. We are just not clear about the roadmap and how you plan to deal with searching for and displaying occurrences. > Do you have any concrete issues with it that you need solved before the > 2-3 week deadline? Which are those? How do you propose to solve them? > See the 2 items above. As to how we propose to solve them - quite honestly we initially proposed to solve them by creating unique objects for each occurrence. But we are here discussing this because we want to know how you propose to solve them. If you have a clear plan and roadmap for these features then we would like to contribute and help. We raised this topic quite specifically to find out IF anyone has considered these items, and if so, HOW they are proposed to be achieved. We are only trying to find out if our client's objectives are in line with the community objectives and if that can result in constructive collaboration. Again, please don't think Im angry, I really do value any input we can get and hope we can give back. Tom |
From: Johannes R. <rag...@ad...> - 2012-04-19 00:10:32
Attachments:
signature.asc
|
let's calm down. occurrences as individual objects - this wouldn't go into plone.app.event core, because it's bound to one specific and valid usecase but won't work for any of the many others. it would just raise a lot of problems. anyways, this discussion showed that need an occurrence traverser and more views (some calendar views, for example). occurrences as individual objects can be implemented through an addon, extending and overriding some plone.app.event specific behavior and write some views and search forms. the only thing is: plone.app.event is still alpha and we should talk about the API first, since i plan to move some more stuff to plone.event. but, you could also try to modify your requirements and try to meet the use case with the current approach: one event only. so this narrow use case cannot run into ugly side effects (lennart's typo problem is in fact very hard to solve). i guess this is a hard decision, really! -- programmatic web development di(fh) johannes raggam / thet python plone zope development mail: of...@pr... web: http://programmatic.pro http://bluedynamics.com |
From: Róman J. <ro...@mo...> - 2012-04-19 00:44:28
|
On Thu, Apr 19, 2012 at 02:10:17AM +0200, Johannes Raggam wrote: > let's calm down. +1 > occurrences as individual objects - this wouldn't go into > [...] > > occurrences as individual objects can be implemented through an addon, > [...] > > but, you could also try to modify your requirements and try to meet the > use case with the current approach: one event only. so this narrow use > case cannot run into ugly side effects (lennart's typo problem is in > fact very hard to solve). So perhaps it would be better to define use cases in which situations it is important to see the actual occurence and in which cases not. You had an idea with an intermittend calendar view which shows all occurences until you end up at the actual event/occurence view. I like the idea, even though which means we would have to define which calendar view the user would see: weekly? monthly? For me, it seems to be a view, rather than a search problem ... Cheers, -- Róman Joost *RECENT PROJECTS* www.bullsmasters.com.au www.pancreaticcancer.net.au www.allanlanger.com.au www.uonservices.org.au www.asiapacificforum.net Mooball IT = Internet 13 Rowland Street Coorparoo, Brisbane QLD 4151 mob: +61 (4) 1455 3212 skype: mooballdotcom Tel: +61 (7) 3843 0516 Fax: +61 (7) 3843 2316 http://www.mooball.com |