In my previous post, I spoke about Jon Udell's work with iCalendar feeds and his push toward acceptance and compatibility of iCalendar feeds on the Internet. With electronic scheduling and calendaring become a more popular method to manage ones life, the ability to share this information with others also becomes increasingly necessary.
In response to this problem, Jon Udell, Ben Fortuna (creator of iCal4J), and I have started an initiative to standardize the iCalendar validation process, to ensure that calendars indeed will work with any system that consumes them:
http://icalvalid.wikidot.com/
We've also begun work on an XML schema for representing information that validation utilities can use to validate iCalendars. This validation process will notify the end user about variations from the standard, and will indicate areas of their iCalendar that may be incompatible with other systems, along with recommending alternatives.
If you're interested in validation of iCalendars, then please visit the Wiki.
Thanks,
-Doug
Thursday, February 5, 2009
Tuesday, January 6, 2009
iCalendar feeds
Hi everyone,
Jon Udell from Microsoft has been doing some interesting work lately involving iCalendar feeds, their current status, and where they need to go for future acceptance.
Among the libraries he's using to test are:
http://blog.jonudell.net/2009/01/05/icalendar-validation-issues-1-and-2-blank-lines-prodid-and-version/
http://blog.jonudell.net/2009/01/06/icalendar-validation-issue-3-quoted-printable-vs-html/
Sam Ruby has also posted about an iCalendar Validator:
http://intertwingly.net/blog/2009/01/03/iCalendar-Validator
Check these out if you get a few minutes.
-Doug
Jon Udell from Microsoft has been doing some interesting work lately involving iCalendar feeds, their current status, and where they need to go for future acceptance.
Among the libraries he's using to test are:
- iCal4J
- DDay.iCal
- iCalendar.py
- vObject
http://blog.jonudell.net/2009/01/05/icalendar-validation-issues-1-and-2-blank-lines-prodid-and-version/
http://blog.jonudell.net/2009/01/06/icalendar-validation-issue-3-quoted-printable-vs-html/
Sam Ruby has also posted about an iCalendar Validator:
http://intertwingly.net/blog/2009/01/03/iCalendar-Validator
Check these out if you get a few minutes.
-Doug
Tuesday, December 2, 2008
MVP Library
Hi all,
It's been a while since I've posted, and I thought I'd start posting more regularly.
Lately, I've been tinkering with the idea of making an MVP (Model-View-Presenter) class library open-source for the general public's benefit. Our team has spent many, many months getting this library setup correctly, and I think other people could benefit from our efforts.
One of the major problems with most people's MVP structure is they violate one of the most principal MVP rules:
The Presenter is in control.
For example, in nearly all MVP setups I've seen, the View (i.e. a Windows Forms application) creates a presenter object and a model object, wires them up, and runs. Ideally, the View should be separated from this process, and not be involved. Another rule that is frequently violated is that the View should be separated from the UI layer - in other words, you should not turn your UI layer into the View.
The class library we've been working on tries to enforce as many design rules as it can without being cumbersome and unfriendly. It also makes Dependency Inversion an implicit requirement, making most projects more "plug and play" than they otherwise would be.
In any case, if it does go open-source, it will likely be named DDay.MVP, and DDay.MVP.WPF, for WPF applications, and will be opened as a project on SourceForge.net and posted on ddaysoftware.com.
Any thoughts?
-Doug
It's been a while since I've posted, and I thought I'd start posting more regularly.
Lately, I've been tinkering with the idea of making an MVP (Model-View-Presenter) class library open-source for the general public's benefit. Our team has spent many, many months getting this library setup correctly, and I think other people could benefit from our efforts.
One of the major problems with most people's MVP structure is they violate one of the most principal MVP rules:
The Presenter is in control.
For example, in nearly all MVP setups I've seen, the View (i.e. a Windows Forms application) creates a presenter object and a model object, wires them up, and runs. Ideally, the View should be separated from this process, and not be involved. Another rule that is frequently violated is that the View should be separated from the UI layer - in other words, you should not turn your UI layer into the View.
The class library we've been working on tries to enforce as many design rules as it can without being cumbersome and unfriendly. It also makes Dependency Inversion an implicit requirement, making most projects more "plug and play" than they otherwise would be.
In any case, if it does go open-source, it will likely be named DDay.MVP, and DDay.MVP.WPF, for WPF applications, and will be opened as a project on SourceForge.net and posted on ddaysoftware.com.
Any thoughts?
-Doug
Labels:
c#,
class libraries,
dependency inversion,
MVP Architecture
Monday, March 3, 2008
New Blog!
Hi everyone,
Many of you have noted that my blog has been offline. I've been tinkering with the idea of making a "global" blog space separate from our web server, so I've finally taken action. Welcome to the new blog!
I'll be posting news about our different projects, and keeping notes of things I find interesting or useful. Anyhow, I hope you enjoy it!
-Doug
Many of you have noted that my blog has been offline. I've been tinkering with the idea of making a "global" blog space separate from our web server, so I've finally taken action. Welcome to the new blog!
I'll be posting news about our different projects, and keeping notes of things I find interesting or useful. Anyhow, I hope you enjoy it!
-Doug
Subscribe to:
Posts (Atom)