You are not logged in.
Thanks for stepping in and helping things along in my mini absence. Haven’t got time today to address this topic but a couple of pointers:
Specifying ranges of dates is on the cards and partially implemented in my head. Think I can do it but remember that you need to put the year in the date ranges or it’ll get muddled up next year (unless the article is set to expire before the same date rolls around next year!). FYI, date ranges will probably be specifed with two full dates separated by
21-feb-09 TO 5-mar-09, 11-mar-09 TO 14-mar-09 etc). Using a hyphen is too messy.
The minical always links to the current day when you click on it unless you override that with the
The ‘today’ flag is just a flag and it depends on your CSS rules as to whether the style overrides your event styles. Try changing the order of your style rules if you find ‘today’ is interfering. And look into using
classlevels="cellplus" to promote events to the cell level for easier styling.
I might need to look into this particular application. The calendar is primarily designed for events on different days. It can schedule more than one event per day but the dates you specify for recurrence are just dates, not times. At leat, I’ve never tried specifying times as well; it might work! But either way, the “today” flag only highlights the current day. Also, I can’t remember if the most recent event of a day is displayed first or last in a cell. Again I’ll have to test it and find out, sorry.
Using smd_cal_now (and perhaps smd_if_cal or smd_if) you might be able to check which event is occurring ‘now’ and style it differently with smd_cal_class.
Last edited by Bloke (2009-02-21 09:11:15)
After thinking about it over the weekend, I believe that if the project proceeds I am going to go El’s route. If you guys can take a look at the below structure and let me know if you see any red flags I would appreciate it.
One issue I had was ease of use for the end user. I am going to assign a log in group that is just for people who are doing the rentals. They will only see the Rental Articles. This should make it friendly for the end user. They should also be able to easily input the information since there will only need to be a couple of fields to be filled in.
Guys, please let me know if you see any issues with the above structure.
the properties [ + Rentals ] entered into the system as Articles.
Makes sense to me.
the end user will: … (3) Use the category field to select the property that the rental is for.
(1) and (2) make sense but I wonder how you are going to keep the category list up to date: you imply there is one Category per property for rentals. But if there’s also one Article per property, when a new property becomes available, will someone have to enter the details in the Article and also create a new Category in case someone wants to rent the property too? Or are rentals completely separate to properties?
When viewing the actual property, I will filter the calendar by the Category Field
I think I get this. So if you are viewing 23 Acacia drive (an Individual Article) then you will make sure the calendar has
?show=23-acacia-drive so it only shows the availability that relates to that property? Very clever, I like it.
A few things to consider:
?c=) because that will filter the article list AND the calendar (unless of course you assign the — redundant — 23-acacia-drive Category to the property and the rental)
maintain="show"in the calendar tag so when you browse next/prev month the current category is retained
?show=(or whatever name you call it) variable for a match with the list of events in that cell
c(this might not be necessary, it depends on your implementation above)
It’s not trivial but I think it’s doable.
Last edited by Bloke (2009-02-23 14:19:01)
Thanks for the quick response.
You are correct, creating new properties will be a bit cumbersome, unless I can figure out a smoother system. for the immediate need, the properties are fixed.
All the cleverness credit goes to Els. I was thinking of tackling it a differnt way until he opened my mind up to this possibility.
Can you please explain a little about the first bullet point. I did think that another alternative was to use the sections as the filter. By doing this, I would have a seperate section for each property and then have the Property and Rentals share the same section. do you think this maybe a better approach? Would this be smoother and more legant?
Hi Stef, me again. Well, I am working with tru_tags to handle ‘tags’, well, I does work good, but NO with future events (articles). There is a way to handle ‘tru_tags’ with future events?
Thanks in advance!
ONE is LOVE
All the cleverness credit goes to Els.
Yeah, when she showed me what she’d done on that booking site of hers I was like “wow, never thought of using the calendar like that” and it immediately sparked off some more ideas for the plugin. If there was a Textpattern Innovations award I’d nominate Els :-)
Can you please explain a little about the first bullet point.
I think you might run into trouble with using the default category but now I think more about it I’m not sure. If you are in section properties and viewing
site.com/properties/23-acacia-drive then you are looking at an Individual Article. As soon as you try and view a category
site.com/properties/?c=23-acacia-drive you are in an Article List context.
Thus, you will have to be clever about the way you view articles and will have to make sure you only show “1 article” when in the properties section, regardless of the category you are viewing. It is made more awkward by the fact the category contains the property name (aka the url title) so you have to extract that from the URL and show the correct article if using TXP’s default
Using a dedicated URL variable means that you never view the articles themselves by category as it is solely used by the calendar for organising content. The fact the variable you choose happens to represent a TXP category is immaterial. By using a different variable, TXP itself will not try and be clever and switch from Individual article to Article List context as you navigate from your property list to an individual property.
Your second thought of putting them all in one section might work insofar as the category then might work more easily (or maybe not…!), at the expense of having to maintain a list of sections. Can you not use cat2 (or a custom field radio set via glz_custom_fields) as the “type” of property (e.g.
buy) and filter using that? Hmmm, that probably doesn’t help either.
The fundamental problem here is that you are having to create two articles to represent — in effect — the same property, which smells hacky to me. There has to be a better way but I can’t figure it out right now. Would it help if the date ranges were in the calendar plugin so you could have one “property” and use the
extrafield to list when it is rented out e.g.
21-feb-09 TO 28-feb-09, 5-mar-09 TO 8-mar-09?
EDIT: mind you, with only 255 characters in a custom field, it’s going to get pretty tight in there and you’ll have to keep revisiting properties to remove rental dates that have passed just so you have enough space to store dates that are coming up.
Last edited by Bloke (2009-02-23 15:11:32)
There is a way to handle ‘tru_tags’ with future events?
No idea! I thought tru_tags just stored its information in the
keywords field, which is available (as a list) from the individual article event in the calendar? But if the tru_tags tags are limited to current articles (i.e. no
time="future" option then I think you are ‘stuck in the past’ so-to-speak, sorry :-(
I agree with the fundamental problem, but because the plug in allows me to filter by section, I thought that when looking at site.com/properties/23-acacia-drive if in the form I had the calendar set for “section=“23 Acacia Drive” I would be in good shape.
Now I know that the property would also fall in the event calendar (since it would be in the same section, but I will just bury it in the past.
The date range in the extrafield, which was my original approach, is not feasable (the more I thought about it) because it would be almost unmanageable from the end users point of view even if the plug in could accomidate it.
Thanks for your answer. Still I’m waiting for some solution… by the way, do you know about some plugins for TAGs? Maybe you developed some one.
I’m trying the search of my site… and I can’t see , in the results, FUTURE events… what’s wrong? Please help!
ONE is LOVE
when looking at site.com/properties/23-acacia-drive if in the form I had the calendar set for “section=“23 Acacia Drive” I would be in good shape.
Yeah that should work as long as you don’t have clickable links from the already-booked events themselves; otherwise they’ll point to site.com/23-acacia-drive/url-title instead of site.com/properties/23-acacia-drive, unless you do some clever rewriting or a bit of jiggery pokery when creating the calendar cells.
The date range in the extrafield… would be almost unmanageable from the end users point of view even if the plug in could accomidate it.
OK, no probs. It needs doing so I’m going to try and get it working anyway.
Just a random thought, how about:
The downside is that TXP will complain that you have several articles with the same name when you save them (it allows this; it just warns you).
Alternatively, tell the end user to create a new article with some other unique info in the url-title (it could be anything, property code, dates, what they had for breakfast, whatever: you’ll never see it) and have them enter the property name in custom1. You can then do the same “if” logic but compare custom1 in the event with the individual article url-title.
If the end user has to type in (or select) the property name whether they are picking from a dropdown category list, a dropdown select list or typing it in a url-title / custom field you might as well use the custom field to “tie” the two records in the two sections together.
Even better (and less prone to error perhaps) than using the property name would be to use a property code utilising some naming convention that you devise, e.g. 23 acacia drive is 0023-aca-dri. As long as the person creating the Property in the first place ensures that the url-title of the article uses the property code and then every time it is referenced from the rental articles you use the same code, everything gels nicely.
Like I say, just a thought. It may or may not have legs.
Last edited by Bloke (2009-02-23 15:58:33)