IRC 2007/03/06

16:16 < vmx> i think scott won't join us. should start without him?
16:17 < jfhv> Yes, the session is logged - we can speak about the selection API if you want.
16:17 < vmx> have you take a look at it? what do you think about it?
16:17 < jfhv> And about your commitment in WYMeditor, also
16:18 < jfhv> I'm not sure I can do it in MSIE
16:18 < jfhv> Scott has some problems in Safari, too
16:19 < jfhv> I think FF is a better platform
16:19 < vmx> have you seen the msie wrapper for the dom selection api (somewhere in the web)
16:19 < jfhv> So I agree with what you said in your e-mail
16:19 < vmx> it's much easier in firefox
16:19 < vmx> what i said about the selection api?
16:20 < jfhv> About the next release: having different levels of implementations
16:20 < vmx> ic
16:21 < jfhv> We can make a full-featured WYMeditor for FF
16:21 < jfhv> And a limited one for the other browsers...
16:21 < jfhv> And try to implement all the features for 0.3.1, for example
16:22 < jfhv> Do you have the URL of the MSIE wrapper.
16:22 < jfhv> ?
16:22 < vmx> i'm searching
16:23 < vmx>
16:25 < vmx> you said, you are not sure if you can do it in msie. but without the selection api it is almost impossible to make it "wym"
16:25 < vmx> it = wymeditor
16:26 < jfhv> Perhaps you mean generating XHTML strict ?
16:27 < jfhv> 0.2 is WYM. It has limitations, but it works in MSIE...
16:28 < vmx> i mena things like only one empty paragraph
16:28 < vmx> even if you press enter several times
16:29 < jfhv> OK, I see
16:29 < jfhv> Did you test the wrapper?
16:29 < vmx> no, i've just found it
16:30 < vmx> if this wrapper works, also my selection api shuld be possible
16:30 < jfhv> OK. He says it's a work in progress...
16:30 < vmx> i tried to keep it as small as possible to make implementation easier
16:31 < vmx> it=selection api
16:33 < jfhv> Looking at
16:35 < jfhv> How do you think we've to write the methods?
16:35 < jfhv> In jquery.wymeditor.js, or in the browsers specific files?
16:36 < vmx> i think the whole selection api needs t be in browser specific files, as msie don't use the dom standard
16:37 < jfhv> OK. So maybe it would be interesting to start with FF?
16:37 < vmx> for ff it's almost finished in my prototype
16:38 < jfhv> Yes. I guess some code has to be modified in jquery.wymeditor.js, too.
16:41 < vmx> hm, i just took a look at my code
16:42 < vmx> it isn't very browser specific. it uses almost only the attributes defined before
16:42 < vmx> so perhaps only the attributes need to go into the browser specific code, and the rest can be coded for all of them
16:43 < vmx> but i don#t know if this is possible, as normally the specific code should inherit the code from the geenric case, and not the other way round
16:43 < jfhv> sorry, what do you mean by attributes?
16:44 < jfhv> methods?
16:45 < vmx> attributes are values, or single nodes. the variables at the beginning of
16:46 < jfhv> so, these are properties, I guess?
16:46 < vmx> ah yes
16:47 < jfhv> ok :)
16:47 < jfhv> BTW: the 'subclasses' aren't really subclasses
16:47 < jfhv> They don't herit
16:48 < jfhv> (from Wymeditor obj)
16:48 < jfhv> That's why I need to pass the Wymeditor instance
16:48 < jfhv> ...which becomes this._wym
16:49 < vmx> hm, if i use e.g. mozilla. first wymeditor.js and the wymeditor.mozilla.js will be loaded, right?
16:49 < jfhv> And Wymeditor 'inherits' the subclasses' methods
16:50 < jfhv> Well; all the .js will be loaded, but a WymClassMozilla instance will be created
16:51 < vmx> ic
16:51 < jfhv> So we init the HTML in Wymeditor.prototype.init
16:51 < jfhv> Create the WymClassMozilla
16:52 < jfhv> And the init the iframe
16:52 < vmx> should the selection api part of the wymeditor object, or be independent?
16:53 < jfhv> I guess it should be a generic API, so in jquery.wymeditor.js
16:53 < jfhv> And part of the object
16:53 < jfhv> Not sure, BTW.
16:54 < vmx> i'm also not sure
16:54 < vmx> first i thought it could be made as independent plugin
16:54 < vmx> but it's so specific, so it doesn't make much sense
16:55 < jfhv> Hmm.. In JS, is it possible to get an object as a method of another object?
16:55 < jfhv> Like Wymeditor.prototype.selection
16:56 < jfhv> var sel = this.selection();
16:56 < jfhv> var myvar = sel.original;
16:56 < jfhv> if(sel.isAtStart())
16:56 < jfhv> etc...
16:57 < vmx> what shouldn't work with your code?
16:58 < vmx> i don't understand your question
16:59 < jfhv> Well, I guess we need to use the obj selection as a Wymeditor sub-object...
16:59 < vmx> yes
17:00 < jfhv> So we can write something like:
17:01 < jfhv> Wymeditor.prototype.selection = function() {}
17:01 < vmx> yes
17:01 < jfhv> this returns the selection object
17:02 < vmx> that's how i thought it should work
17:02 < vmx> it would be nice if the properties could be set in the browserpecific files, and the methods in the general one. but i don't think that can be done
17:04 < jfhv> And if we write Wymeditor.prototype.selIsAtStart, etc ?
17:05 < vmx> imho it is cleaner to make a selection object
17:05 < vmx> as you don't need functionality from "outside"
17:05 < vmx> what would we win with Wymeditor.prototype.selIsAtStart?
17:06 < jfhv> Yes, I know it's not very clean, but perhaps we would have more freedom
17:06 < jfhv> We can write generic code and specific one easily
17:07 < jfhv> Like I did with Wymeditor.prototype.exec
17:07 < jfhv> this._exec(cmd);
17:08 < vmx> as the specific code gets executed later, you couldn' you overwrite the general functions with sepecific ones?
17:08 < vmx> like Wymeditor.selection.prototype.isAtStart()
17:09 < jfhv> That should be nice. I didn't know this syntax was possible :)
17:09 < vmx> i'm not sure
17:10 < vmx> but evry object should have "prototype"
17:10 < jfhv> Yes, that's right
17:11 < jfhv> So we need to make some tests...
17:11 < jfhv> figure out how we can work with the sel API.
17:12 < vmx> yes. i'm not used to the javascript oop
17:13 < jfhv> I'm in the same situation :)
17:13 < jfhv> I got Scott's reply:
17:13 < jfhv> I cannot make the chat today. I'm sorry to have to cancel but I just don't have enough time to get everything done this week. I meant to let you know before now but forgot to email you back.
17:13 < jfhv> I uploaded my latest code to the SVN server under scott/test/01/ so you guys can take a look. There is not really much difference between the Safari and Mozilla code. The only change so far is that execCommand is triggered by the button mousedown rather than button click.
17:13 < jfhv> If you post today's chat on the wiki I will read it all so I am up to speed for next week.
17:14 < vmx> ok
17:15 < vmx> could sometihng like
17:15 < vmx> WymClassMozilla.prototype.selection = this._wym.selection;
17:15 < vmx> WymClassMozilla.prototype.selection = function() {
17:15 < vmx> work?
17:15 < vmx> and then you set the properties within WymClassMozilla.prototype.selection
17:16 < jfhv> I'm not sure for the first line
17:17 < vmx> ok, we'll see
17:17 < vmx> i tihnk we should go on with the next topic
17:18 < jfhv> Yes. If you want, I can give you an account on the SVN
17:18 < jfhv> So you can make a branch
17:18 < vmx> that would be nice
17:18 < jfhv> And make tests there
17:18 < jfhv> OK.
17:19 < jfhv> About 2)
17:19 < jfhv> Safari implementation:
17:19 < vmx> scott is missing, so there won't be much to say about
17:20 < jfhv> Yes, but I can already modify the click events to mousedown :)
17:20 < jfhv> Not so difficult
17:21 < jfhv> OK.
17:21 < jfhv> About 3)
17:21 < jfhv> The way to code (object literals vs. prototyping)
17:21 < jfhv> What is your opinion?
17:22 < vmx> i read about it
17:22 < vmx> and i must say, the more you read about, the more you get confused
17:22 < dreszka> lol
17:22 < jfhv> I agree :)
17:23 < vmx> jquery makes heavy use of literal objects, so i thought "that is cool"
17:23 < jfhv> Yes. But I like the prototyping syntax. It's easy to add methods.
17:23 < vmx> but then i foundout, that although jquery uses literals, it uses prototyping
17:24 < vmx> i hope i understood it right, jquery uses literals just as a shorter way to write things
17:25 < vmx> and not the way e.g. uses them
17:25 < vmx> i good read is:
17:26 < vmx> i was very confused when i wrote you the mail. no everything is a bit clearer
17:27 < jfhv> I don't know. Perhaps the namespacing is an important benefit when you use literals.
17:27 < vmx> we should/can prototyping with literal syntax
17:27 < dreszka> sorry guys but i'll have to go.
17:27 < dreszka> I didn't say almost anything, but don't think i was asleep ;)
17:27 < dreszka> simply i'm such a newbie at js programming that i couldn't do anything but read what you are saying.
17:27 < dreszka> BTW I have worked on the CSS / skins / interface customization system, working directly on the trunk. Please don't hesitate to take a look and to send me any critics or suggestions.
17:27 < dreszka> Thank you for this very interesting session.
17:28 < vmx> ok, cu daniel
17:28 < dreszka> I'll read the rest of the conversation this evening. bye bye.
17:29 < jfhv> bye Daniel :)
17:29 -!- dreszka [n=admin@…] has left #wymeditor []
17:30 < vmx> if it's ok, i've another thing
17:30 < jfhv> About namespacing: all the code is in the Wymeditor object
17:30 < jfhv> Except global constants
17:30 < vmx> sure
17:30 < jfhv> var aWYM_INSTANCES, and so on
17:31 < jfhv> The way they are named - I guess it's ok ?
17:33 < vmx> to be honest, i don't like the hungarian notation that much
17:33 < jfhv> OK. What do you prefer?
17:33 < vmx> name them in a way you know what they are ;)
17:34 < jfhv> What do you mean?
17:34 < vmx> a variable should have a name where you can guess what type it has
17:34 < jfhv> (a is fo arrays, s for strings, etc)
17:35 < vmx> e.g. i often use for booleans names with "is" or "has in front
17:35 < vmx> arrays are often plural
17:36 < vmx> nodes have names like "startNode"
17:36 < vmx> i would describe it as "wrapping the type into natural language"
17:36 < vmx> but it's ok for me to use your convention
17:37 < jfhv> OK.
17:38 < jfhv> I think we must use something like wym_...
17:38 < jfhv> to avoid conflicts with other JS code
17:38 < vmx> perhaps we can strip the "s" from strings away, as almost all varables are strings
17:38 < vmx> but only if they are global
17:39 < jfhv> Hmm, yes. The only problem is for aWYM_INSTANCES
17:39 < vmx> i think there shouldn't be a conflict, as they are all part of the WYMeditor object
17:39 < jfhv> No - these are global vars
17:39 < vmx> ok
17:40 < jfhv> I need aWYM_INSTANCES to get the Wymeditor instances
17:40 < vmx> i ment the other variables
17:40 < jfhv> Globals, too
17:41 < vmx> ah, i've take a lok at your code. "s" in front of strings is ok. all other js objects don't have a prefix
17:41 < jfhv> But maybe they can become local, I didn't think about that specific problem...
17:42 < jfhv> Currently, they're instanciated one time
17:43 < jfhv> If they become local, they will be instanciated in each Wymeditor instance
17:43 < vmx> another thing about the coding style. the wiki page has different information than it actually is. e.g. tab vs. spaces
17:43 < jfhv> Yes, I just copied/pasted Scott's ideas :)
17:44 < jfhv> I've to work on that specific question
17:44 < jfhv> Daniel prefers spaces, too.
17:45 < jfhv> What's your opinion about tabs/spaces?
17:45 < vmx> 4 spaces
17:46 < jfhv> I use 8 spaces. Do you mean real spaces? I mean, we don't use tabs anymore ?
17:47 < vmx> ah ok. for me they look like tabs. but it can be vim that disaplys the spaces as such
17:47 < vmx> i use 4 spaces, especiall for cases like:
17:48 < jfhv> Currently we use tabs.

17:48 < vmx> if (something == very && long != too
long == for

17:48 < vmx> a != single && line)
17:48 < vmx> {
17:49 < vmx> the code
17:49 < vmx> }
17:49 < vmx> so i indent the second "if" line 2 times
17:49 < vmx> with 8 spaces it's almost impossible
17:51 < jfhv> OK. I think there's no problem if we use 4 spaces... We'll see with Daniel and Scott.
17:51 < vmx> ok
17:51 < vmx> any things left, or are we finished for today?
17:53 < jfhv> I think we can close the meeting.
17:53 < jfhv> I'll create an account for you on the svn
17:54 < jfhv> Can I introduce you on the website/forum/... ?
17:55 < vmx> hm, if it's ok for you i'll keep some time in the background
17:55 < jfhv> OK, NP.
17:56 < vmx> one think i wanted to say
17:57 < vmx> by accident i found natural docs
17:57 < vmx> i like the way the coumentation is made in the source. i find all thos "@param" stuff hard t oread
18:01 < jfhv> (sorry, phone call)
18:04 < jfhv> OK, I'll take a look at that. I'm sorry, I've to go now. Maybe we can meet up again later this week?
18:06 < vmx> yes, cu
18:08 < jfhv> I'll keep you in touch. Bye.