IRC 2007/09/14

15:14 < jfhv> OK, Volker, what's the status of the SAPI implementations?
15:15 < vmx> i've commited fixes (as you've probably seen) to isAtStart() and isAtEnd()
15:15 < vmx> thex worked for me in msie and firefox
15:15 < vmx> these are the most important functions for wym-features
15:16 < bermi_ferrer_> Volker, is there any chance of adding unit tests for the SAPI?
15:16 < vmx> sure, but someone needs to write them
15:16 < bermi_ferrer_> I added a unit test framework to wym, and have committed some tests for bugs found on the Parser
15:17 < vmx> nice
15:17 < bermi_ferrer_> it is really simple to create test cases, and that way we can verify what works and what doesn't on different environments
15:18 < jfhv> how do you think we can use it to test the SAPI?
15:18 < vmx> we could but one would either need to write additional crossbrowser functionality or write browser specific tes
15:18 < vmx> you would need to simulate cursor positions
15:19 < bermi_ferrer_> cant we position the cursor with the SAPI?
15:19 < vmx> and setting cursor position (selelctions) differs from browser to browser
15:19 < vmx> not yet (and i personlly haven't planned it)
15:20 < bermi_ferrer_> how do we do to get the pointer back to a selection after pressing one action button?
15:20 < vmx> my design for the SAPI was with wym-features in mind. but it can be of course extended
15:20 < vmx> you can restore a previous selection easily
15:21 < jfhv> maybe we'll need some user interaction
15:21 < vmx> it's a big deifference between restoring something and setting it
15:22 < jfhv> Is the FF implementation finished?
15:22 < bermi_ferrer_> if we can set the caret programatically in a cross browser manner it would be possible to create unit tests and perhaps adding more functionalities
15:22 < vmx> restoring/saving selection fucntionality has every browsers
15:23 < vmx> jfhv: yes, msie too (at least i hope so :)
15:23 < vmx> bermi: that#s the problem you can't set it in a crossbrowser way
15:24 < vmx> my proposition: writing done manual test cases make much more sense
15:24 < vmx> so someone would need to move the cursor in a given way
15:25 < bermi_ferrer_> isn't it possible to use something like selenium for that?
15:25 < bermi_ferrer_> if you need to do it manually it will never get done
15:25 < bermi_ferrer_> Hi Daniel
15:26 < vmx> hi daniel
15:26 < jfhv> IIRC Selenium couldn't be used with iframe/designMode
15:26 < vmx> haven't heard of selenium yet
15:26 < jfhv> you can record actions in your browser
15:27 < jfhv> and replay them
15:27 < jfhv> that would be a great step if we could use it
15:27 < vmx> a crossbrowser way to set the selection would again need a tests
15:27 < bermi_ferrer_> jfhv: did you have a look at yui Rich Text Editor?
15:28 < jfhv> a little
15:28 < bermi_ferrer_> I think they implemented a selection api
15:28 < jfhv> did you take a look at the code?
15:29 < bermi_ferrer_> and they first implemented it in Safari, so they only used arcane js an not browser specific/dom functions
15:29 < bermi_ferrer_> I did have a look at it
15:30 < vmx> for no i don't think writing tests for SAPI makes sense. it's to much trouble for to less outcome
15:31 < jfhv> well, I'm not sure
15:31 < bermi_ferrer_> writing tests has an incredible outcome, makes fixing bugs much easier and allows us to add new functionality without fear of breaking working code
15:32 < vmx> i second that. but not in the sapi case
15:33 < jfhv> Volker, isn't deleteIfExpanded missing in MSIE implementation?
15:33 < vmx> jfhv: oh you're right, but that's easy
15:33 < bermi_ferrer_> I'm a unit testing fan, an trust me, it always pays off, plus it is a great source of documentation
15:34 < bermi_ferrer_> I can help on get unit tests for the SAPI
15:34 < jfhv> sorry, phone call
15:34 < bermi_ferrer_> I need to know how it really works
15:34 < vmx> bermi me too. but as i said you would first need to write a cross browser implementation for setting the selection
15:34 < vmx> then you would need to write tst for that
15:34 < vmx> alss this to test the sapi?
15:35 < vmx> alss=all
15:35 < bermi_ferrer_> I'll investigate a way for setting the selection
15:35 < vmx> if we write test, then browser specific
15:35 < bermi_ferrer_> tests need to be cross browser
15:36 < vmx> bermi: don#t get me wrong, tests would be really nice, but i tthink we could spend the time on more important things
15:36 < vmx> i know unit tests are time savers, but as i said before: not in this case
15:37 < vmx> i think we can stop that discussion. now we know each others point of view :)
15:38 < bermi_ferrer_> can we simply start selecting and element in the editor using it's id and start testing the code from that known node?
15:38 < jfhv> I'm back. Anyway, I can test again Selenium to see if we can use it.
15:39 < vmx> bermi: it is doable and perhaps not that hard, but it'll be tiem consuming
15:40 < vmx> sleelcting nodes e.g. is pretty easy, but getting al cases might not be that easy
15:40 < vmx> we'll see. just do it! if you've questions about the selection apis of the browsers you can always drop me a mail
15:41 < jfhv> I guess we firstly need to finish SAPI implementations
15:41 < bermi_ferrer_> I will try to add the tests, I want to get familiar with the SAPI and adding tests for it might be a good exercise
15:41 < jfhv> What about Opera and Safari?
15:41 < vmx> scott is working on the safari implementation
15:42 < vmx> opera is still open
15:42 < vmx> opera shouldn't be that hard
15:43 < bermi_ferrer_> in safari there is no way to know where the cursor is inside of an iframe, is that necesary for the SAPI to work correctly?
15:43 < vmx> bermi: a small warning, there are still some issues with the implementations between msie and firefox. so please don't get crazy if small annoyances occur
15:44 < vmx> bermi: so you can't get the selection?
15:44 < jfhv> sorry, phone call again :(
15:44 < bermi_ferrer_> no
15:46 < bermi_ferrer_> sorry, phone
15:46 < vmx> doesn't yui rte also use iframes?
15:47 < vmx> it does. so there needs to be a way to get it working
15:47 < vmx> any further things about the SAPI or can we switch to the next topic?
15:48 < jfhv> About SAPI, what have you planned for next weeks?
15:48 < vmx> not much. i'll be away for 2 weeks (namibia)
15:49 < vmx> the sapi is almost finished
15:49 < jfhv> OK, what remains?
15:49 < vmx> as far as i need it for the wym features
15:50 < vmx> the deleteIfExpanded for msie (i'll do this onwe before i'll leave)
15:50 < vmx> and the opera implementation
15:50 < jfhv> OK, I can work on the Opera impl
15:50 < vmx> the next thing will be the start of wym features. these go hand in hand with a new event handling structure
15:51 < jfhv> right
15:51 < jfhv> I'll see with Scott tomorrow about the Safari impl
15:51 < jfhv> So 2) New events handling architecture
15:51 < vmx> perhaps i'll be also available tomorrow (we'll see)
15:52 < jfhv> that would be great
15:52 < bermi_ferrer_> back
15:52 < jfhv> cool
15:52 < vmx> i've discussed that with bermi one time in the past
15:52 < jfhv> 2) New events handling architecture
15:52 < vmx> this is the idea:
15:53 < vmx> a general event handling function with (sometimes) browser specific implementations
15:53 < vmx> a bit like the sapi, but it's not a new class
15:54 < vmx> so you'll implement everything crossbrowser, except you need browser specific features
15:54 < vmx> at the moment the event code is the browser specific files
15:54 < jfhv> OK, so porting event handlers to the main class
15:54 < bermi_ferrer_> what do you mean with browser specific features on the event handling context?
15:55 < vmx> i can't think of a real example but let's use a fictional
15:55 < bermi_ferrer_> first of all, are we talking about browser events or WYM events
15:55 < vmx> browser events
15:56 < vmx> or wait, what's the difference
15:57 < vmx> a fictional case: if you press end-key msie only goes to the character before the last one. you would then overwrite the end-key handler in the msie specific file
15:57 < bermi_ferrer_> the difference is creating new events that others can subscribe to, like onIsertUrl
15:57 < bermi_ferrer_> onIsertUrl = onInsertUrl
15:58 < vmx> i remember, you liked the obeserver pattern
15:58 < bermi_ferrer_> yes, I think an event handling API can be the key for a successful plugin architecture
15:59 < vmx> i haven't thougt about plugins. good point
16:00 < bermi_ferrer_> if I create a media management plugin I would like to be able to notify subscribed observers when I add a new video so the Parser respects/transforms the <object> tag... just an example
16:00 < vmx> bermi: i think you remember when we talked about event handling. we had (roughly) the same ideas. mine ideas can be seen as a subset of yours
16:01 < vmx> i haven't digg so deep into event handling yet
16:01 < bermi_ferrer_> YUI has a great implementation for handling events
16:01 < bermi_ferrer_> it can even scope events
16:01 < vmx> so the best would be if you will implement a new handling
16:02 < vmx> but please keep it simple
16:02 < vmx> keep it simple as jquery is :)
16:03 < bermi_ferrer_> jQuery does not have a custom event plugin?
16:03 < bermi_ferrer_> I think prototype.js does
16:03 < jfhv> I found  http://blog.brandonaaron.net/2007/08/19/new-plugin-live-query/
16:03 < vmx> no it hasn't. my comment wasn't about events, but about simplicity
16:03 < jfhv> but it's a little bit different
16:04 < vmx> the subscriber/observer principle can easily get very difficult
16:06 < vmx> all i want is a big (ugly) onkeydown function where i can handle wym-features
16:06 < vmx> everything else can be done in a nice way
16:07 < bermi_ferrer_> this is the yui event implementation  http://pastebin.com/me0f33fe
16:07 < jfhv>  http://developer.yahoo.com/yui/event/ also
16:09 < vmx> jquery has custom event handling:
16:09 < vmx>  http://simonwillison.net/2007/Aug/15/jquery/ (scroll to "Handling events")
16:11 < vmx> so the best would be to use this functionality if ye want custom events
16:11 < vmx> as i said my time is limited. anythong important we should talk about (i'll be away from 21.9 to 6.10)
16:12 < bermi_ferrer_> how can you subscribe to a custom event using jQuery?
16:13 < vmx> jQuery(document).bind('stuffHappened', function(event, msg) {
16:13 < vmx> alert('stuff happened: ' + msg);
16:13 < vmx> });
16:16 < bermi_ferrer_> that seems pretty easy, should we abstract it into a wym method to make it simple for plugin/developers to just create a stuffHappened method on the WYM class or plugin?
16:17 < vmx> yes i think it should be abstracted
16:18 < bermi_ferrer_> we could also add a WYM.triggerEvent('stuffHappened', [...]) instead of jQuery(document).trigger('stuffHappened', Hello!?);
16:22 < jfhv> OK. Bermi, maybe writing a prototype would be a good idea?
16:23 < vmx> the main thing sould be: clean up the current handling mess
16:24 < bermi_ferrer_> I agree
16:25 < jfhv> OK. Volker: what about merging 0.4 and 0.5?
16:26 < vmx> is there much to merge from 0.4?
16:27 < vmx> but yes i think we should merge
16:27 < vmx> further 0.5 developments hould g oto trunk
16:27 < jfhv> OK
16:27 < jfhv> I can do it next week
16:27 < vmx> my plan: 0.5 will be released with SAPI (perhaps not yet in use) and new event handling
16:28 < vmx> 0.6 will be the first wym release
16:28 < vmx> (0.6 will lead to big discussions.)
16:29 < vmx> jfhv: another thing
16:29 < vmx> about the msie expando problem
16:29 < jfhv> I'd like to have the media API and the true skin system asap
16:30 < jfhv> OK, let's talk about the expando problem :)
16:30 < vmx> i've just written a mai lto jquery-dev. with 1.2 there's quite nice solution. but it'll need a patched 1.2 atm. i hope my cahnges get into trunk
16:30 < vmx> john resig do't want it in the trunk, but perhaps some other core dev
16:31 < jfhv> some URL to check?
16:31 < jfhv> anyway that's great news
16:31 < vmx>  http://vmx.cx/tmp/jquery/noexpando/demo.htm
16:32 < vmx> take al ook at the source
16:32 < vmx> jqHtmlNoexpando()
16:32 < vmx> with my plugin you can disable expandos, and restore them
16:33 < vmx> so we could disable them, then run some designmode command, and restore them again
16:33 < vmx> if my jquery patch won't get to trunk we would need to patch it ourselfes, but it won't have any sideeffects to jquery
16:34 < jfhv> sounds really cool, nice work Volker
16:34 < vmx> so if you think "damnit john resig". that isn't right
16:34 < vmx> he had our expando problem in mind while developing jquery 1.2
16:35 < vmx> i had quite a few nice chats with him
16:35 < jfhv> I don't think "damnit john resig"!
16:36 < vmx> :)
16:36 < vmx> is it ok if i'll leave now?
16:36 < jfhv> Did you test it already with WYMeditor?
16:37 < vmx> no
16:37 < vmx> so if you've anything important, jsut drop a mail, i'll be there until 21.9
16:38 < jfhv> I'll give it a try if I find some time.
16:38 < jfhv> OK, thanks for the meeting. Bye.
16:38 < vmx> cu
16:38 < bermi_ferrer_> see you
16:38 < jfhv> Bermi, have you some time to talk about 3) ?
16:39 < bermi_ferrer_> jfhv, do you want to add a logging bot for this channel?
16:39 < jfhv> I log sessions in irssi
16:40 < bermi_ferrer_> I'd like to implement it once I understand the selection API, we have an event system, and 4) clear
16:41 < jfhv> Sounds OK for me.
16:42 < jfhv> Did you take a look at  http://dev.jquery.com/view/trunk/plugins/ui/uiUpload/ ?
16:44 < jfhv> Maybe we can use more jQuery UI plugins, I think they're doing a great job.
16:44 < bermi_ferrer_> you need flash??
16:45 < jfhv> Hmm, I've read about one which didn't use flash
16:46 < bermi_ferrer_> the one you just pointed me to does not use flash
16:46 < jfhv>  http://docs.jquery.com/UI/Upload
16:46 < bermi_ferrer_> BTW I already have gmail/like file uploaded integrated on Akelos
16:47 < jfhv> how does it work?
16:47 < bermi_ferrer_> using iframes to post the form
16:48 < bermi_ferrer_> but it needs a server side component
16:48 < jfhv> I remember you already talked about that technique.
16:49 < jfhv> Is there some code I can check out?
16:49 < bermi_ferrer_> Server side:  http://svn.akelos.org/trunk/lib/AkActionView/helpers/file_upload_helper.php
16:50 < bermi_ferrer_> Javascript:  http://svn.akelos.org/trunk/public/javascripts/file_uploader.js
16:51 < jfhv> OK, I think I get the idea.
16:51 < bermi_ferrer_> server side code needs to keep uploaded files into a temp space and then modified the $_FILES global to point to the pre-uploaded files
16:52 < bermi_ferrer_> it also needs to remove files once the parent form is submited
16:52 < bermi_ferrer_> it is not easy to implement
16:52 < bermi_ferrer_> I still need to write some tests and documentation for it
16:55 < bermi_ferrer_> first of all I want to learn more about the selection API, there are many issues that might be fixed using it and I think we should focus on them
17:08 < bermi_ferrer_> once I play with the SAPI I'll have a clearer view for implementing the Media API, Skins...
17:08 < bermi_ferrer_> I have to go now, see you!
17:09 < jfhv> see you!