>> MF> Just tell me about something that you would like to implement as DW's
>> MF> extension and you can't due to the API's limitations
>>
>> For one example, setting focus. Focus needs to be able to be set from
>> anywhere, to anywhere. This is especially problematic with dynamic
>> content in a floater as doc.write has, i assume unintended,
>> consequences in regards to focus.
MTeF> I really don't want to sound rude or offend you, but I have the strong
MTeF> feeling you haven't spend that much time looking at DW's API. Yes, you can
MTeF> set focus (of course) and document.write() isn't supported at all inside
MTeF> extension's
MTeF> GUI. DW expose innerHTML both as a read/write property
Show me the code to set focus anywhere in a floater onmouseover the
floater itself. It doesn't exist. The focus() method is _only_
available on form objects according to the documentation. Custom
floaters are really the coolest thing about DW so that's where I think
the problem is most glaring.
doc.write and innerHTML is the same thing...it's all writing out html
with _javascript_, and it's old, lame, and slow. I'd though that was
implied. It's all DOM 1. I wouldn't even mind DOM 1 if it was fully
implemented, but it's not. Hell, replace all of the HTML crap with
Flash + Royale (if it's as good as advertised), and I could care about
the DOM support even less.
btw, I spent two weeks looking at 2004 in my spare time before my trial
was up.
>> oaters themselves need all of the DOM events...onmouseover is a big
>> e. Onmouseover...floaters need to be able to be focused.
>> Onrightclick is another big missing one.
MTeF> Floaters support a bunch of events. Two you may want to investigate are
MTeF> "onShow()" and "onHide()"
onshow and onhide have nothing to do with onmouseover, or
onrightclick, and onblur, and ondoubleclick, and every other DOM event.
>> doc.write being the only way to dynamically alter content is so 5
>> years ago, slow, and has obvious code maintenance problems. The world has
>> DOM 2 now. Fourth generation browsers are dead, and doc.write is lame.
MTeF> I really have can't imagine how you got into this idea that DW's use
MTeF> document.write()...
MTeF> It's clearly stated inside the docs that document.write() isn't supported in
MTeF> extensions GUIs and you have to use the DOM (same for editing documents)
Yeah...the old, lame, and slow based DOM. See above.
>> A simple DTD says so much about an XML document...it's vastly
>> superior to the few paragraphs and examples given.
MTeF> Sincerely, unless I need to validate, I don't think a DTD is a good
MTeF> documentation by itself. But I guess it's a matter of tastes
You must really dislike all the W3C standards then. They seem to think
they are great for documentation, and I would agree.
>> Homesite's built in objects and functions are documented clearly and named
>> logically.
MTeF> Would you mind giving me an exmple where DW doesn't follow this standards?
Can't think of anything major off the top of my head, that isn't a
personal preference, but the fact that the dom and dreamweaver object
methods are so scattered around in different sections is annoying when
you are not sure what you are looking for.
>> It also benefits from the fact that tons of preexisting
>> documentation exists for the WSH languages and COM objects.
MTeF> That's the good thing of HS's extensibility but, again, your mileage may
MTeF> vary, I can't stand VBScript and I always find annoying to see that so many
MTeF> documentation in this area focus on VBScript.
MTeF> DW internally use Mozilla's Rhino _javascript_ 1.5 engine, and there is plenty
MTeF> of preexisting documentation on it too, much more than the one available for
MTeF> WSH.
I think JS 1.5 is great, but I'd bet a nickel a large number of people
would trade it for VBS, or Kix, or Perl...
I also own three books that cover various aspects of WSH or touch on
it, and their are many more available. It's not the language that
needs documented anyway...there isn't any _javascript_ docs in DW
extensibility manuals. It's the objects and their methods.
Extensibility is about allowing what the primary application
developers do not have time to do, or what they haven't seen a need
for. Not just different ways of doing what the app already does.
>> I can't remember who developed it, but I'm sure you have seen that
>> cool new DW data wizard that was recently released. It's
>> great...except DW's data limitations wont allow an editable
>> grid, just viewing.
MTeF> Are you talking about the one included in DRK? As far as I know it use Java
MTeF> under the hood (with a C++ > Java bridge).
MTeF> What's the purpose of having an editable grid inside an extension? Of
MTeF> course, if you need it badly, you can use C++ or Flash for it.
What's the purpose?! Obviously you haven't had the pleasure of working
in an IDE that allows direct editing of a db table while working on a
data heavy project. Do you think VS.Net goes as far as providing
stored procedure debugging, in addition to editing of data, just
because a few developers want it? The 6 guys who developed web matrix
in their spare time felt it important enough to include in a free
product as well.
I mean...we are supposed to coding a language that used to be called
database markup language in an IDE that doesn't allow editing of
data. As if that makes sense.
>> I only use DW on one platform...I don't see why I have to be
>> limited. Would it be hard to allow Windows people to use WSH and allow
>> Mac people to use AppleScript?
MTeF> What I like about DW is that I can develop an extension on my Windows box
MTeF> and distribute or sell it cross-platform. That's a huge benefit since, last
MTeF> time I heard, around 40% of DW users base is on the Mac.
Glad it does someone good, but 99.9% of DW users don't sell extensions
either. I don't think trading power for enhancing extension sales
revenue is a good tradeoff at all. I respect why you differ on this
point though.
If I want to bring all the functionality of the IIS and MS DNS MMC's,
and Query Analyzer into my IDE, I could do it with Homesite...I
couldn't dock the app anywhere, but I don't want to be limited because
the app has to run on a Mac.
>> Directory listings read from the HD directly every time instead of
>> using the Windows API's ability to cache directory listings.
MTeF> Back in DW 4 days I sold a quite succeful extension, a Snippets Floater. It
MTeF> uses DWFile for directory listing, people used it with 1000+ snippets and it
MTeF> perfomed just fine, actually faster than DW's MX native implementation.
MTeF> Would you mind showing me a scenario were this would affect a real world
MTeF> extension? How many recurring directory listing would you need and why?
Anything that does recurring directory listings :) Either way, it's a
heck of a lot slower than the scripting.fso.
>> still has all of Flash's UI
>> problems like lack of right-click, and scroll button though.
MTeF> Have you checked Flash 2004? I think not :-)
Guess I'll have to...not before Royale comes out though. Good to hear
they fixed that stuff.
>> MF> Well, actually DW predates Mozilla, the XML menus were based on the
MTeF> very
>> MF> early draft of XUL (back in 1999)
>>
>> Four years...The extensibility team been on hiatus since then?
MTeF> No, but there was no need to update the XML structure. What's wrong with
MTeF> that?
Noting is wrong with the XML, it's the missing the rest of XUL, XBL,
and XPCOM specs that's all. :)
p.s. I complain, because I want to be cheering. Otherwise I wouldn't
give a damn.
--
jon
mailto:[EMAIL PROTECTED]
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
