Symphony.

For instance, how does the decision to have two versions impact Mark Lewis's commitment to developing documentation?

Let me give you an update on where documentation stands now. I am committed to Symphony's documentation and I have no reason for that to change at this time. The recent news does not change current plans for documentation and if anything, only solidifies its release. A word of caution, however, I have less time than I had when I made this commitment a while back. Nevertheless, there is a working draft but it does have stuff missing, including entire chapters.

I'll be chatting with the Symphony team in the coming days. Don't expect documentation to be released with Symphony 2, but shortly after.

Thanks for the update, Mark.

I wonder whether there are pieces of the documentation that you'd feel comfortable commissioning from some of us... we could whip up quick drafts and submit them for your review. Even if you'd want to heavily edit them, it still might save you some time to have others face the blank page...

Thanks, Mark. Glad to hear that documentation will soon be arriving on the heels of the release of Symphony 2. I'm looking forward to it.

I could go without documentation (guide-like), if I just had a search (perhaps specialized Google) for the API / Source Code docs. Sorry Alistair. :-\

Actually, even in-line docs. Are fine. :D haha.

we could whip up quick drafts and submit them for your review. Even if you'd want to heavily edit them, it still might save you some time to have others face the blank page...

It's not so much the lack of information but rather its organization. I feel this is best done in the beginning with one person establishing the flow and style. I will most certainly put it out for critical review and anyone that feels they have something important to add can provide it at that time (credit will be given to the contributor).

Makes sense, Mark, thanks. And good luck ;)

Would this be best done via a Wiki? One owner could write the core content, and the community adds as and when required.

Would this be best done via a Wiki?

I think so. It might even be possible to set up a PDF export for offline reading.

It might even be possible to set up a PDF export for offline reading.

that would be a great option.

Great news to get the uncertainty out of the air. This means I can start my next project worry-free in the latest Symphony 2 version (Final? Probably you will find some more bugs to squash).

Does this means that initiatives to build a Symphony 1.7 to Symphony 2 converter can be safely started?

Final?

Yup. I'll make an announcement soon, just been busy. ;)

Does this means that initiatives to build a Symphony 1.7 to Symphony 2 converter can be safely started?

It sure does. I reckon a great many people would appreciate this, but from my understanding this could be quite a lot of work!

Will we get the calendar back with the release of Symphony 2?

I don't see why not, however I won't have time for this before the 2.0 release, which will be soon.

Scott, are there any news about the time and date picker?

Hey Nils, might the jQuery Date Picker extension be sufficient for your needs?

We aren't going to build a calendar widget into the S2 core like in S1.7, since that should be the job of extensions. I've looked into porting the S1.7 date calendar, which will probably be easy, and I'm happy to do this if there's enough demand.

I've looked into porting the S1.7 date calendar, which will probably be easy, and I'm happy to do this if there's enough demand.

I'd like to vote for it because I really liked the 1.7 calendar :)

Voted. Liked it, too :)

I liked it, too. But sometimes you are even a lot faster using the standard input field in S 2. So I would love to see it as an option for date and time fields.

Well, and indeed jQuery rocks! This is the JavaScript framework of choice for me, so I would like to see it in Symphony's core (and/or extensions) as well.

I'm not a big fan of seeing a javascript framework in Symphony's core. At least not if it is locked to one specific framework (only my two cents).

Well, Scott has his own framework, which has no documentation, and the project needs javascript...

I don't think we have a choice but to adopt another library.

That's good enough for me. I should have time within the next 2 weeks, though I'll pretty much just be doing a straight port of the 1.7 calendar, not adding new features.

I don't think we have a choice but to adopt another library.

Indeed. My JS used in the core was originally intended to be used by extensions also, but I've been scaling this back ever since 1.7. I don't think it's a good idea for extensions to use or rely on the core JS, but instead access the core JS functionality through adding classes to HTML, e.g. ul.tags.

I've started a new thread on including JS with extensions.

That's good enough for me. I should have time within the next 2 weeks, though I'll pretty much just be doing a straight port of the 1.7 calendar, not adding new features.

Are there any news concerning the calendar port?