Wednus Project: wants advice

[sundew]

Hi all,

I am developing an open source DHTML project named Wednus Window.
http://wednus.com

Wednus Window is a DHTML Web-Application Windowing System. It shell
websites/web-applications with fully customizable DHTML window objects
and users also can change its skin, so it can goes well with an
website layouts.

I have just released v0.3.5 beta1 and working on beta2 now, and hope t
get your sugestions or any ideas on improving it.

Thanks.

Sundew Shin
Wednus Project
Manager/Developer
http://wednus.co

--
sunde
-----------------------------------------------------------------------
sundew's Profile: http://www.highdots.com/forums/member.php?userid=8
View this thread: http://www.highdots.com/forums/showthread.php?t=133064

[Random]

sundew wrote:

Hi all,

I am developing an open source DHTML project named Wednus Window.
http://wednus.com

Wednus Window is a DHTML Web-Application Windowing System. It shells
websites/web-applications with fully customizable DHTML window objects,
and users also can change its skin, so it can goes well with any
website layouts.

I have just released v0.3.5 beta1 and working on beta2 now, and hope to
get your sugestions or any ideas on improving it.

Thanks.

Sundew Shin
Wednus Project
Manager/Developer
http://wednus.com
--
sundew
------------------------------------------------------------------------
sundew's Profile: http://www.highdots.com/forums/member.php?userid=89
View this thread: http://www.highdots.com/forums/showthread.php?t=1330649

The functionality is impressive. Good work.

As far as advice, I caught three bugs:
I noticed that when you double-click to bring it back from
'windowshade' into normal size, it seems to have a problem displaying
the content of the window. In one attempt, it appeared blank. In
another, it appeared filled with red.

When dragging the 'window' by the top bar (on the demo page), if you
move the mouse too quickly the 'window' may stop following.

Also, on the main page of the site, when dragging the 'window' it
highlighted text on the page.

Pretty cool stuff overall.

Now you get to document it. :)

[sundew]

Thanks for your time and advice, Random

I noticed that when you double-click to bring it back from
'windowshade' into normal size, it seems to have a problem displaying
the content of the window. In one attempt, it appeared blank. In
another, it appeared filled with red.
can you tell me the webbrowser you were using and demo page you've go
this result?
if the demo was http://wednus.com/wednus0.3.5b1/samples/wom.htm ,
then the 'filled with red'-part might have happened after clickin
'[put outside object into core]' link. if it was the case, it worke
as it supposed to be.

When dragging the 'window' by the top bar (on the demo page), if you
move the mouse too quickly the 'window' may stop following.
Typically, a WW is composed by 10 to 30 DIV htmlelements and thei
backgroud images. I guess, the fancier the skin(often with bigge
image size in total) become, the slower the WW(Wednus Window) objec
respond. It was funny because I gave exactly same feedback to othe
DHTML window author who asked me some help. :o Thanks a lot.
realized I need to improve this part more.
Pretty cool stuff overall.
Now you get to document it. :)

I became realized that documentation is more(or equivalently, at least
important than the actual project is, but it is still hard to me
probably harder than programming..

anyway, thank you again

--
sunde
-----------------------------------------------------------------------
sundew's Profile: http://www.highdots.com/forums/member.php?userid=8
View this thread: http://www.highdots.com/forums/showthread.php?t=133064

[Random]

sundew wrote:

Thanks for your time and advice, Random
No problem at all, man.

I noticed that when you double-click to bring it back from
'windowshade' into normal size, it seems to have a problem displaying
the content of the window. In one attempt, it appeared blank. In
another, it appeared filled with red.

can you tell me the webbrowser you were using and demo page you've got
this result?

IE6/Win2k
http://wednus.com/wednus0.3.5b1/samples/wom.htm
if the demo was http://wednus.com/wednus0.3.5b1/samples/wom.htm ,
then the 'filled with red'-part might have happened after clicking
'[put outside object into core]' link. if it was the case, it worked
as it supposed to be.
That explains the field of red, yes. You're absolutely right.
Not sure why it would have shown up blank prior to that, though.

When dragging the 'window' by the top bar (on the demo page), if you
move the mouse too quickly the 'window' may stop following.

Typically, a WW is composed by 10 to 30 DIV htmlelements and their
backgroud images. I guess, the fancier the skin(often with bigger
image size in total) become, the slower the WW(Wednus Window) object
respond.

....

You're probably right that it's due to the complexity. I'm not sure
that you'll be able to solve it, but you can probably work around it by
registering onMouseUp events for the document as a whole to better
identify if the user is still dragging.

Pretty cool stuff overall.
Now you get to document it. :)

I became realized that documentation is more(or equivalently, at least)
important than the actual project is, but it is still hard to me.
probably harder than programming..

In my opinion, documentation is the hardest (and least rewarding) part
of development. I wish you luck where that's concerned.

[sundew]

Not sure why it would have shown up blank prior to that, though.
I finally have confirmed this bug myself and have fixed it. It was a
issue only on IE browsers.
I have implemented the 'rolling' feature by backing up the middle par
of a WW in an invisible temp node when user dblclick the titlebar. an
when user dblclick again, it retrieves the 'middle part' and relink th
node to the original node, and the problem was right there.
For some unknown reason, when an object moves around in nodes b
'appendChild' method, IE looses the object's style.visibility property
so it needs some refreshment of this prop. so what I've done was
change the prop. to 'hidden' first and change it back to 'visible'.
Thank you so much! It could be one of most difficult bugs to fin
because it doesn't bring up any script errors.

About the issue on loosing control while dragging or resizing, I hav
been considering this issue from the beginning, and suggested severa
workarounds myself, and here are the results revealed as two plugins.
http://tinyurl.com/8efd6
http://tinyurl.com/bw5ua

actually, with its own event/exception handler, debugger and run-tim
profiler, WW is mainly designed for openning safer channel fo
workaround-efforts on challenging cross-browser tasks. so, it wasn'
difficult to make such things, but workarounds are just going aroun
and not going through anyway.
you can probably work around it by registering onMouseUp events for th
document as a whole to better identify if the user is still dragging.

but this one was different. what an amazing suggestion! you just hi
the nail on the head.
I can see that you really have great understanding on how all object
and events are working in the browser area. :cool:
I'll remodel the dragger. BTW, one thing is, the most common case i
looses its dragging control is when a WW has an IFRAME as its core.
And when dragging happen to loose its control on the IFRAME, since tha
onmouseup event will be fired *in* the core(IFRAME) area, the host(W
holding) page loose the onmouseup event.. hmm

anyhow, I owe you whole lot already. thank you so much, Random.
hope I also have something to help you back. =

--
sunde
-----------------------------------------------------------------------
sundew's Profile: http://www.highdots.com/forums/member.php?userid=8
View this thread: http://www.highdots.com/forums/showthread.php?t=133064

[sundew]

Not sure why it would have shown up blank prior to that, though.
I finally have confirmed this bug myself and have fixed it. It was a
issue only on IE browsers.
I have implemented the 'rolling' feature by backing up the middle par
of a WW in an invisible temp node when user dblclick the titlebar. an
when user dblclick again, it retrieves the 'middle part' and relink th
node to the original node, and the problem was right there.
For some unknown reason, when an object moves around in nodes b
'appendChild' method, IE looses the object's style.visibility property
so it needs some refreshment of this prop. so what I've done was
change the prop. to 'hidden' first and change it back to 'visible'.
Thank you so much! It could be one of most difficult bugs to fin
because it doesn't bring up any script errors.

About the issue on loosing control while dragging or resizing, I hav
been considering this issue from the beginning, and suggested severa
workarounds myself, and here are the results revealed as two plugins.
http://tinyurl.com/8efd6
http://tinyurl.com/bw5ua

actually, with its own event/exception handler, debugger and run-tim
profiler, WW is mainly designed for openning safer channel fo
workaround-efforts on challenging cross-browser tasks. so, it wasn'
difficult to make such things, but workarounds are just going aroun
and not going through anyway.
you can probably work around it by registering onMouseUp events for th
document as a whole to better identify if the user is still dragging.

but this one was different. what an amazing suggestion! you just hi
the nail on the head.
I can see that you really have great understanding on how all object
and events are working in the browser area. :cool:
I'll remodel the dragger. BTW, one thing is, the most common case i
looses its dragging control is when a WW has an IFRAME as its core.
And when dragging happen to loose its control on the IFRAME, since tha
onmouseup event will be fired *in* the core(IFRAME) area, the host(W
holding) page loose the onmouseup event.. hmm

anyhow, I owe you whole lot already. thank you so much, Random.
hope I also have something to help you back. =

--
sunde
-----------------------------------------------------------------------
sundew's Profile: http://www.highdots.com/forums/member.php?userid=8
View this thread: http://www.highdots.com/forums/showthread.php?t=133064

[Richard Cornford]

sundew wrote:

I am developing an open source DHTML project named
Wednus Window.
http://wednus.com

Wednus Window is a DHTML Web-Application Windowing
System. It shells websites/web-applications with fully
customizable DHTML window objects, and users also can
change its skin, so it can goes well with any website
layouts.

I have just released v0.3.5 beta1 and working on beta2
now, and hope to get your sugestions or any ideas on
improving it.

My first impression is of code that is massively more complex and
convoluted than it needs to be. That alone will place a significant
barrier in the way of the code being used in web applications as any
experienced web application developer would take one look at the source
and see a development/maintenance nightmare. Good documentation might
elevate that concern, if it revealed the system as having a small and
simple public interface, but my impression is that that isn't true so
complete documentation would not give such an impression.

In browser window systems are a problem crying out for an OO solution,
and a design separating responsibilities into easily identified units.
For example, a window manager object and a window instance object,
responsible for behaviour related to the state of the individual
windows, while the manager co-ordinates the windows, handling things
like z-index stacking. While that sort of concept may be buried
somewhere in the code it is a long way from being apparent.

A second impression is of code authored by individuals who don't
understand why they are doing what they are doing. An example might be
the line:-

| WS.load = function(cat,name){document.write('<scr'+
| 'ipt type="text/javascript" src="'+
| WS.path.root+cat+'/'+name+
| '/'+name+'.js"><\/scr'+'ipt>');};

- form webnus.js, where the voodoo of splitting up and then
concatenating the script elements is combined with the escaping of the
slash in the closing '</' sequence, but both in a file that was designed
to be imported, and so not subject to that related issue at all.

Similar examples include code that branches to accommodate Natescape 4's
object model features, while other code assumes dynamic support for -
document.createElement -.

That impression of unskilled implementation is re-enforced by the
occurrence of both of the "dismiss this code out of hand" criteria for
javascript; browser detection by UA string, and using eval to resolve
property accessors. From dom.js:-

| WS.func.thisDivOnTop = function(id){
| var t = 0;
| var z = (document.layers) ? ".zIndex" : ".style.zIndex";
| var fun = (document.getElementById) ? "document.getElementById":
| "MM_findObj";
| var arr = (document.layers) ? document.layers : (document.all) ?
| document.all.tags("DIV") :
| document.getElementsByTagName("DIV");
| for(var i = 0; i < arr.length; i++){
| var oz = eval("arr["+ i +"]" + z);
| if(oz > t){
| t = oz;
| }
| }
| var obj = eval(fun + "(id)");
| if(obj) eval(fun +"('"+ id +"')"+ z +" = parseInt("+ t +")+ 1");
| };
|
|
| //Detect the browser vendor and version number
| WS.cvar.agt = navigator.userAgent.toLowerCase();
| WS.cvar.is_nav = ((WS.cvar.agt.indexOf('mozilla')!=-1) &&
| (WS.cvar.agt.indexOf('spoofer')==-1) &&
| (WS.cvar.agt.indexOf('compatible') == -1) &&
| (WS.cvar.agt.indexOf('opera')==-1) &&
| (WS.cvar.agt.indexOf('webtv')==-1) &&
| (WS.cvar.agt.indexOf('hotjava')==-1));
| WS.cvar.is_gecko = (WS.cvar.agt.indexOf('gecko') != -1);
| WS.cvar.is_ie = ((WS.cvar.agt.indexOf("msie") != -1) &&
| (WS.cvar.agt.indexOf("opera") == -1));
| WS.cvar.is_opera = (WS.cvar.agt.indexOf("opera") != -1);

The examples all use invalid HTML, and there are examples of the use of
deprecated mark-up within the script. This deficiency on the part of the
author appears to have resulted in the impression that modern browsers
only operate in quirks mode. In the event that the script be exposed to
formally valid HTML it will significantly malfunction. In code written
for a specific context that might be acceptable but code aimed at
general use in a web application should really be written so that
aspects of browser behaviour that are influenced by factors external to
the script are taken into account and coped with.

The system as a whole does not have any facility to negate the IE
browser SELECT element burn-through problem. It is difficult to imagine
a web application that does not feature at least one SELECT element.

Being able to drag a window out of the top of the page in the browser
window is not a good idea as it risks rendering the title bar and button
of that window inaccessible (making continued use of that window
problematic).

Clicking the minimise buttons on the window appears to result in them
disappearing forever.

A web application using an in-browser window system will likely want to
react to the user's interactions with those windows. That would probably
be best facilitated by allowing external code to attach event handlers
to aspects of the window objects. That is, conceptually at the window
object level, not reaching into the HTML DOM for the window and
attaching browser event handlers to the contained elements. Being able
to attach arbitrary code to be executed when the window loads its
contents, is re-sized, scrolled and closed, would probably be the
minimum an in-browser widow system should facilitate.

Richard.

[sundew]

My first impression is of code that is massively more complex and
convoluted than it needs to be.I admit it. In browser window systems are a problem crying out for an OO solution,
and a design separating responsibilities into easily identified units.hmm.. I might need to study other real OSs and see how those units wer actually implemented.
A web application using an in-browser window system will likely want t
react to the user's interactions with those windows. That woul
probably be best facilitated by allowing external code to attach even
handlers to aspects of the window objects. That is, conceptually at th
window object level, not reaching into the HTML DOM for the window an
attaching browser event handlers to the contained elements. Being abl
to attach arbitrary code to be executed when the window loads it
contents, is re-sized, scrolled and closed, would probably be th
minimum an in-browser widow system should facilitate.I know what you're talking about, and you just draw me a clea inspiration on improving current object model of WW. thanks.
A second impression is of code authored by individuals who don'
understand why they are doing what they are doing. An example might b
the line:-
...Similar examples include code that branches to accommodate Natescap
4's
object model features, while other code assumes dynamic support for -
document.createElement -.Whole code was written all by myself, so, yes, on many parts, I didn' know what I was doing, and sometimes I mimicked others code even thoug
I wasn't fully convinced. The #1 goal of this project always b
supporting most browsers including all IE/Mozilla/KHTML/Opera relate
browsers. On the way I was trying to make WW more 'generic', I becam
numb at adopting crazy-unintuitive-nasty-but-working code of others.
appreciate your advice.
The examples all use invalid HTML, and there are examples of the use of
deprecated mark-up within the script. This deficiency on the part o
the
author appears to have resulted in the impression that modern browsers
only operate in quirks mode. In the event that the script be expose
to
formally valid HTML it will significantly malfunction. I can't agree more. It will be the first target at revising the code. In code written for a specific context that might be acceptable but cod
aimed at
general use in a web application should really be written so tha
aspects of browser behaviour that are influenced by factors external t
the script are taken into account and coped with.I think do literally understood this part but got a feeling that maybe won't never understand what it deeply implies. can you explain i
little more please?
The system as a whole does not have any facility to negate the IE
browser SELECT element burn-through problem. It is difficult t
imagine
a web application that does not feature at least one SELECT element.just amazed.. did you open up whole modules? how did you know? I know a mothod using an IFRAME to cover them up if necessary from:
http://www.codetoad.com/forum/20_22736.asp
, but if you know any better methods or workarounds, please let m
know.
Clicking the minimise buttons on the window appears to result in the
disappearing forever.maybe there was an error on the demo you tested. minimizing a WW wil be resulted as an icon showing on the position predefined. which dem
did you try?
Being able to drag a window out of the top of the page in the browser
window is not a good idea as it risks rendering the title bar an
button
of that window inaccessible (making continued use of that windo
problematic).this one, I noticed it could be an issue as you just pointed out. so

prepared a plugin for preventing such event. I didn't implement it a
a default because I wanted to give more freedom to users.
http://tinyurl.com/d4gl2

what can I say?
thanks a lot, Richard

--
sunde
-----------------------------------------------------------------------
sundew's Profile: http://www.highdots.com/forums/member.php?userid=8
View this thread: http://www.highdots.com/forums/showthread.php?t=1330649

[Random]

sundew wrote:

My first impression is of code that is massively more complex and
convoluted than it needs to be.

I admit it.

In browser window systems are a problem crying out for an OO solution,
and a design separating responsibilities into easily identified units.

hmm.. I might need to study other real OSs and see how those units were
actually implemented.

This is something to take very seriously. I didn't look at your code
because I assumed it would be a few hours' browsing (which is why I
only remarked on the functionality), but it is very important to keep
everything properly encapsulated in appropriate objects, such as Rob's
WednusWindowManager and WednusWindow suggestions.

It's equally important that, regardless of the complexity or neatness
of the underlying code, you provide a clear, easy-to-use, intuitive
interface for developers implementing your project. Ideally, we would
never have to look at the underlying code and be able to take advantage
of a simple, well-documented API.

I don't want to have to know how it works-- I don't have time for that.
I need to be able to make it work with as little effort as possible. It
has to be magic.
....

A second impression is of code authored by individuals who don't
understand why they are doing what they are doing. An example might be
the line:-
...Similar examples include code that branches to accommodate Natescape
4's
object model features, while other code assumes dynamic support for -
document.createElement -.

Whole code was written all by myself, so, yes, on many parts, I didn't
know what I was doing, and sometimes I mimicked others code even though
I wasn't fully convinced. The #1 goal of this project always be
supporting most browsers including all IE/Mozilla/KHTML/Opera related
browsers. On the way I was trying to make WW more 'generic', I became
numb at adopting crazy-unintuitive-nasty-but-working code of others. I
appreciate your advice.

Keep the voodoo for masking <script></script> tags if you're going to
be writing <script> tags. Someone out there is going to try to
copy/paste the code into the document itself, and this should not break
your code.
....

In code written for a specific context that might be acceptable but code
aimed at
general use in a web application should really be written so that
aspects of browser behaviour that are influenced by factors external to
the script are taken into account and coped with.

I think do literally understood this part but got a feeling that maybe I
won't never understand what it deeply implies. can you explain it
little more please?

In the environments in which your project will be implemented, there
are ten thousand and more factors that you cannot possibly control.
Your job is to take them all into account and make sure your script
keeps working (or at least doesn't break anything else).

....

Clicking the minimise buttons on the window appears to result in them
disappearing forever.maybe there was an error on the demo you tested. minimizing a WW will

be resulted as an icon showing on the position predefined.

You also gave the icon a default position, I assume.

Being able to drag a window out of the top of the page in the browser
window is not a good idea as it risks rendering the title bar and
button
of that window inaccessible (making continued use of that window
problematic).this one, I noticed it could be an issue as you just pointed out. so I

prepared a plugin for preventing such event. I didn't implement it as
a default because I wanted to give more freedom to users.
http://tinyurl.com/d4gl2

I didn't have a problem with this because the left border of the frame
allowed me to move the WW around as well. Of course if you somehow
manage to drag it off the left and above the top, you're still screwed.

[Random]

sundew wrote:

Not sure why it would have shown up blank prior to that, though.
I finally have confirmed this bug myself and have fixed it. It was an
issue only on IE browsers.
I have implemented the 'rolling' feature by backing up the middle part
of a WW in an invisible temp node when user dblclick the titlebar. and
when user dblclick again, it retrieves the 'middle part' and relink the
node to the original node, and the problem was right there.

Isn't it simpler to just set its CSS display property to 'none' when it
needs to go away, and then back to 'block' when it's restored?
For some unknown reason, when an object moves around in nodes by
'appendChild' method, IE looses the object's style.visibility property,
so it needs some refreshment of this prop. so what I've done was,
change the prop. to 'hidden' first and change it back to 'visible'.
Probably has a problem keeping track of it because visibility is
inheritable.

....

you can probably work around it by registering onMouseUp events for the
document as a whole to better identify if the user is still dragging.

Actually I'll have to take that back -- what if someone already has an
onMouseUp handler for their document? Either your script will break
theirs, or theirs will break yours.
.... BTW, one thing is, the most common case it
looses its dragging control is when a WW has an IFRAME as its core.
And when dragging happen to loose its control on the IFRAME, since that
onmouseup event will be fired *in* the core(IFRAME) area, the host(WW
holding) page loose the onmouseup event.. hmm

That being the case, registering an onMouseUp for the parent document
wouldn't fix it anyway, because the mouse won't be over the document
when that event fires -- it'll fire for the document in the iFrame,
which you can't control.

Instead, you might consider covering the iframe with a div or span
(transparent, of course) while it's being dragged. Then get rid of the
div or span when dragging ceases. You can either get rid of it entirely
or just set its CSS display property to 'none'.

Some versions of some browsers aren't too good at placing layer-like
elements over iframes, but it's a start.

Anyway, glad I could be of some help.

[Richard Cornford]

Random wrote:
<snip>

Keep the voodoo for masking <script></script> tags ...

<snip>

The voodoo is doing - '<scr'+'ipt>' -; splitting up and then
concatenating the script element. It should not be kept. The issue is
that HTML parsers encountering the sequence '</' within a JS string are
allowed to take that to be the end of the script element (as clearly
stated in the HTML specification). The solution is to escape the slash
to '<\/'. When the splitting up and concatenating of script elements
within strings fails to break up the '</' sequence it is not addressing
the real problem, just the known manifestations of the problem.

Neither are necessary in an external JS file, but if either is to be
kept it should be the escaped slash as it solves the real problem,
conforms with the requirements of HTML and is faster to execute as it
involves no additional concatenation operations.

Richard.

[sundew]

In browser window systems are a problem crying out for an O solution, and a design separating responsibilities into easily identifie

units. it is very important to keep everything properly encapsulated i appropriate objects

o.k., I think I have to explain how it has been organized for bette
understanding. maybe I might needed to start this thread from this..

need some term definition first:
WW: Wednus Window: visible, object what you can see and control
WS: Wednus System: abstract, window.document environment wit
'wednus.js' inclusion.

It is true that some are in prematured shape yet, but WS actually ha
several those 'units' implemented. As a browser loads 'wednus.js', W
take over some events and properties it needs from the browsers. sinc
I didn't intend to make WS as a some sort of DHTML OS, I tried to mak
the number of events and properties it controls as small as possible.
so some aspect of WS revealed as weakness of it for being an OS i
Richard's argument, was actually intended.

anyway, once it fully loaded, now WW can be constructed by callin
'WS.wednus' method, So I might can say there is a Window Manager uni
and (Window) Object class(unit)

There are two construction class. one for WW and the other for ski
object, and two data structure, 'window pool' for holding instancies o
WW and 'skin pool' for skin instancies.
Skin object is being instantiated as it referred on the way a W
constructing. skin object is constructed only one for each skin, s
when there is constructor being called for another WW which would use
skin already loaded will refer and reuse the skin object which stored i
'skin pool'.
[multiple skin demo] http://wednus.com/wednus0.3.5b2/samples/skins.htm
maybe the part I have missed was making them(the units) be 'easil
identified'.
you provide a clear, easy-to-use, intuitive interface for developer
implementing your project.> I don't have time for that. I need to be able to make it work with a
little effort as possible. Rather than encapsulating, I intentionally left most methods opene for direct access, and also prepared abstract interfaces for pp
expecting some 'abstraction' here, and I believed I gave flexibility
but now I think I didn't fully understand what the 'encapsulation
really means in reality. =)
Keep the voodoo for masking <script></script> tags if you're going to
be writing <script> tags. Someone out there is going to try to
copy/paste the code into the document itself, and this should no
break
your code. I haven't thought about it that far. thanks, Richard and Random. I'l keep it in mind.
Your job is to take them all into account and make sure your scrip
keeps working oh. I've been considering exactly what you're saying here.

'window.onresize' event, for example, is one of events what WS listens
WS refreshes the workarea size properties when it catches this event
but there always could be user defined function for this event in th
host page as well. So, to satisfy both WS and user script, I neede
some trick to 'append' event listeners.

window.onresize = function(){alert 'default onresize handler';}; /
the original
var default_onresize = window.onresize; // backup the original
window.onresize = function(){new_onresize();}; // redirect this event

function new_onresize(){
default_onresize();
alert 'attached onresize handler';
}

it works fine, but what if there are more than 2 'window.onresize
listener appending?
what about 100?

So what I'm implementing now is a data structure, say, 'event pool', s
either in WS-level or host page level, when event listener is bein
added, WS stacks the function object in the pool, and when the even
fires, it will excute all the function in the pool as it traverse dow
to the bottom. there are technical difficulties here, but I think
can manage them

--
sunde
-----------------------------------------------------------------------
sundew's Profile: http://www.highdots.com/forums/member.php?userid=8
View this thread: http://www.highdots.com/forums/showthread.php?t=133064

[Random]

sundew wrote a lot of stuff that sounded okay, plus:

Random wrote:

you provide a clear, easy-to-use, intuitive interface for developers
implementing your project.
I don't have time for that. I need to be able to make it work with as
little effort as possible. Rather than encapsulating, I intentionally left most methods opened
for direct access, and also prepared abstract interfaces for ppl
expecting some 'abstraction' here, and I believed I gave flexibility,
but now I think I didn't fully understand what the 'encapsulation'
really means in reality. =)

This is more of a recommendation for ease-of-use. As a developer, if
I'm to implement this, I don't want to _have_ to know about all the
functions and methods and properties.

It should be as simple as:

x = new WednusWindowManager();
x.add(
new WednusWindow(
{
skin: 'MySkin',
title: 'James Brown',
src: 'http://www.google.com/linux?q=James+Brown',
width: '380px',
noresize: true,
onmouseover: function () { this.focus(); }
}
)
);
y.show();
y.minimize();
y.maximize();
y.restore();

et cetera. Again, this is just a recommendation.

It'd be even nicer if I could also say:

Wednesday = new WednusWindowManager(
[
new WednusWindow(
{
// properties
}
),
new WednusWindow(
{
// properties
}
)
]
);
See what I mean? In general, try to pack as much power into ease of use
as you can. Leave complication to the people that want to complicate
things-- people can change the source code if they want to, and
JavaScript will let us do whatever we want with the objects and
prototypes that you're loading anyway.

Keep the voodoo for masking <script></script> tags if you're going to
be writing <script> tags. Someone out there is going to try to
copy/paste the code into the document itself, and this should not
break
your code. I haven't thought about it that far. thanks, Richard and Random. I'll

keep it in mind.

Your job is to take them all into account and make sure your script
keeps working oh. I've been considering exactly what you're saying here.

'window.onresize' event, for example, is one of events what WS listens.
WS refreshes the workarea size properties when it catches this event,
but there always could be user defined function for this event in the
host page as well. So, to satisfy both WS and user script, I needed
some trick to 'append' event listeners.

window.onresize = function(){alert 'default onresize handler';}; //
the original
var default_onresize = window.onresize; // backup the original
window.onresize = function(){new_onresize();}; // redirect this event

function new_onresize(){
default_onresize();
alert 'attached onresize handler';
}

it works fine, but what if there are more than 2 'window.onresize'
listener appending?
what about 100?

So what I'm implementing now is a data structure, say, 'event pool', so
either in WS-level or host page level, when event listener is being
added, WS stacks the function object in the pool, and when the event
fires, it will excute all the function in the pool as it traverse down
to the bottom. there are technical difficulties here, but I think I
can manage them.

I thought about something like that, too-- basically wrapping whatever
the current event handler in your own. The problem though is that I (as
the developer implementing your project) might also be dynamically
adding event handlers (a lot of people seem to be doing this). If I do
that, then I wipe out whatever handler you've loaded.

To some degree you'll run into things you just can't (gracefully) work
around. In some instances you'll have to dip your fingers into the
greater document. It's just a matter of doing it as little and as
transparently as possible, and putting stern warnings in your
documentation. Also, try not to rely on such dippings. In the case of
resizing, it's no big deal -- your WednusWindow won't break if it can't
listen for resize events, right?
Anyway. I gotta run -- keep working it, man.

[sundew]

Isn't it simpler to just set its CSS display property to 'none' when i
needs to go away, and then back to 'block' when it's restored?you were absolutely right. this single tip allowed me to take off bunc of lines and a data structure from the code immediately. thanks a lot!
The problem though is that I (as the developer implementing you
project) might also be dynamically adding event handlers (a lot o
people seem to be doing this). If I do
that, then I wipe out whatever handler you've loaded.good point. what I was thinking for implementing the 'event pool' i

that it monitors the value of target event handler and compare with th
latest one. since user defined event handlers can't be [native code]
unless someone try sth like 'window.onresize = window.onload;'-, it ca
be compared as string, right?. but it won't work when the event handle
overrided dynamically after some user function call.. there might b
no way but 'dynamaically' monitor the string value of event listener.
timer?. well, it's too expensive. If I choose to make it an OS, the
having at least one timer would save whole lot of headache, but
haven't decided it yet because that's going to be whole differen
journey, and not sure whether it's going to be that worthy

--
sunde
-----------------------------------------------------------------------
sundew's Profile: http://www.highdots.com/forums/member.php?userid=8
View this thread: http://www.highdots.com/forums/showthread.php?t=133064

[sundew]

The voodoo is doing - '<scr'+'ipt>' -; splitting up and the
concatenating the script element. It should not be kept.I've been using the trick, o.k., the voodoo, from the early days

needed to documet.write a document.write a string including '<script>
tag, and it was for achieving the goal of loading external J
dynamically on a window.popup object. I did many other voodoo thing
but nothing worked except the one you just pointed out. now I too
them out and the code still work fine on all web browsers what W
supports. it's funny.
and thanks for reminding that I have those illogical parts in my code

--
sunde
-----------------------------------------------------------------------
sundew's Profile: http://www.highdots.com/forums/member.php?userid=8
View this thread: http://www.highdots.com/forums/showthread.php?t=133064

[sundew]

The voodoo is doing - '<scr'+'ipt>' -; splitting up and the
concatenating the script element. It should not be kept.I've been using the trick, o.k., the voodoo, from the early days

needed to documet.write a document.write a string including '<script>
tag, and it was for achieving the goal of loading external J
dynamically on a window.popup object. I did many other voodoo thing
but nothing worked except the one you just pointed out. now I too
them out and the code still work fine on all web browsers what W
supports. it's funny.
and thanks for reminding that I have those illogical parts in my code

--
sunde
-----------------------------------------------------------------------
sundew's Profile: http://www.highdots.com/forums/member.php?userid=8
View this thread: http://www.highdots.com/forums/showthread.php?t=133064

[sundew]

Isn't it simpler to just set its CSS display property to 'none' when i
needs to go away, and then back to 'block' when it's restored?you were absolutely right. this single tip allowed me to take off bunc of lines and a data structure from the code immediately. thanks a lot!
you might consider covering the iframe with a div or span (transparent
of course) while it's being dragged. Then get rid of the div or spa
when dragging ceases. You can either get rid of it entirely or just se
its CSS display property to 'none'.I think it is a great idea too. I'm working on it now, so let you kno

when I get something to show

--
sunde
-----------------------------------------------------------------------
sundew's Profile: http://www.highdots.com/forums/member.php?userid=8
View this thread: http://www.highdots.com/forums/showthread.php?t=133064

[sundew]

The problem though is that I (as the developer implementing you
project) might also be dynamically adding event handlers (a lot o
people seem to be doing this). If I do
that, then I wipe out whatever handler you've loaded.good point. what I was thinking for implementing the 'event pool' i that it monitors the value of target event handler and compare with th
latest one. since user defined event handlers can't be [native code]
unless someone try sth like 'window.onresize = window.onload;'-, it ca
be compared as string, right?. but it won't work when the event handle
overrided dynamically after some user function call.. there might b
no way but 'dynamaically' monitor the string value of event listener.
timer?. well, it's too expensive. If I choose to make it an OS, the
having at least one timer would save whole lot of headache, but
haven't decided it yet because that's going to be whole differen
journey, and not sure whether it's going to be that worthy.
try to pack as much power into ease of use as you can. Leav
complication to the people that want to complicate things--I took your advice. With referring the HTML DOM window objec

description I found at w3schools.com and split th
collections/objects/properties/methods into two groups.

group A: all collections and objects, .open, showModalDialog...
custom mothods
group B: all events & .name, .opener, screenLeft/Top, .focus, .blur
.close, .moveBy/To, .navigate, .resizeBy/To, .scrollBy/To.. & custo
mothods

all elements in group A will be implemented in WS constructor, an
stuffs in group B will be in WW constructor.

so the possible sample code for the upcomming version would be st
like:

var x = new WS.WindowManager();
x.open(
new WednusWindow(
{
skin: 'MySkin',
...
})
);

in case sb needs to get the handle for WW for controlling it in its ow
function:

var y = new WednusWindow(
{
skin: 'MySkin',
...
});

x.add(y);

and become able to do:

y.blur();
y.focus();
y.moveTo(100, 100);
y.close();
...

what do you think

--
sunde
-----------------------------------------------------------------------
sundew's Profile: http://www.highdots.com/forums/member.php?userid=8
View this thread: http://www.highdots.com/forums/showthread.php?t=133064

[Random]

sundew wrote:

The problem though is that I (as the developer implementing your
project) might also be dynamically adding event handlers (a lot of
people seem to be doing this). If I do
that, then I wipe out whatever handler you've loaded. good point. what I was thinking for implementing the 'event pool' is
that it monitors the value of target event handler and compare with the
latest one. since user defined event handlers can't be [native code] -
unless someone try sth like 'window.onresize = window.onload;'-, it can
be compared as string, right?. but it won't work when the event handler
overrided dynamically after some user function call.. there might be
no way but 'dynamaically' monitor the string value of event listener. A
timer?. well, it's too expensive. If I choose to make it an OS, then
having at least one timer would save whole lot of headache, but I
haven't decided it yet because that's going to be whole different
journey, and not sure whether it's going to be that worthy.

I came to pretty much the same conclusions: the most reliable way to do
it would be to monitor it, and that's neither reliable nor elegant. If
you do want to make it a sort of webpage OS, then yes, a 'timer' would
almost certainly be necessary at some point. But don't go that route --
we already have browsers, and I don't think that offering a webpage
'OS' would be will drive adoption. Keep it at 'Window Manager'.

try to pack as much power into ease of use as you can. Leave
complication to the people that want to complicate things--

I took your advice. With referring the HTML DOM window object
description I found at w3schools.com and split the
collections/objects/properties/methods into two groups.

group A: all collections and objects, .open, showModalDialog... &
custom mothods
group B: all events & .name, .opener, screenLeft/Top, .focus, .blur,
.close, .moveBy/To, .navigate, .resizeBy/To, .scrollBy/To.. & custom
mothods

all elements in group A will be implemented in WS constructor, and
stuffs in group B will be in WW constructor.

Seems reasonable and it makes sense. I don't see a problem with that at
all.
so the possible sample code for the upcomming version would be sth
like:

var x = new WS.WindowManager();
Sadly, this doesn't work (please someone correct me if I'm wrong on
this). I've tried to do something like that before, so I could expose
only one global object (i.e. WS) and make all other properties
(WS.name), methods (WS.open()), and constructors (WS.WindowManager())
into members of that object. I couldn't get it to work. I haven't gone
so far as to read the ECMAScript spec with regard to this, but I'm
guessing that according to standard this sort of construct ( new
Identifier1.Identifier2() ) is not valid.
x.open(
new WednusWindow(
{
skin: 'MySkin',
..
})
);

in case sb needs to get the handle for WW for controlling it in its own
function:

var y = new WednusWindow(
{
skin: 'MySkin',
..
});

x.add(y);

and become able to do:

y.blur();
y.focus();
y.moveTo(100, 100);
y.close();
..

what do you think?

Grand. I like it-- it's almost exactly what I was thinking. But as has
already been indicated by others, I can be a bit eccentric (though
there may be better adjectives :). Run it by a few other folk as well
before you spend hours trying to implement it.

[sundew]

[source: grid.js, ActiveWidgets Grid 1.0.1]
http://www.activewidgets.com/

...
$import("xml/table.js");
...

function $import(path){
var i, base, src = "grid.js", scripts
document.getElementsByTagName("script");
for (i=0; i<scripts.length; i++){if (scripts[i].src.match(src)){ bas
= scripts[i].src.replace(src, "");break;}}
document.write("<" + "script src=\"" + base + path + "\"></"
"script>");
}
what do you think about this one?
just another voodoo

--
sunde
-----------------------------------------------------------------------
sundew's Profile: http://www.highdots.com/forums/member.php?userid=8
View this thread: http://www.highdots.com/forums/showthread.php?t=133064

[Lasse Reichstein Nielsen]

sundew <su***********@no-mx.forums.yourdomain.com.au> writes:

what do you think about this one?
just another voodoo?

First, I see that it includes a document.write, so it must be
meant to be used while the page is still loading.
..
$import("xml/table.js");
It has something to do with XML?
..

function $import(path){
var i, base, src = "grid.js", scripts =
document.getElementsByTagName("script");
This should find all scripts so far in the page, which has not loaded
completely yet. It might not include the current script element, although
I guess it does.

I wouldn't depend on the DOM being available before the page has
loaded completely, at least not if the page is XHTML (properly served),
but then again, document.write doesn't work there either.
for (i=0; i<scripts.length; i++){if (scripts[i].src.match(src)){ base
= scripts[i].src.replace(src, "");break;}}
The
scripts[i].src.match(src)
tries to use the string "grid.js" as a regular expression. As such,
the match would be true if scripts[i].src was "bagridajsy.js" or
even "magrid/jscode/foo.js". Use a proper RegExp that matches only
what you want it to, e.g.:
... src = /\bgrid\.js$/i;

Also, the line
base = scripts[i].src.replace(src, "")
suffers from the same problem. You could probably just do:

var scriptSrc = scripts[i].src; // don't do lookup twice (or more)
base = scriptSrc.substring(0, scriptSrc.lastIndexOf("/") + 1);
document.write("<" + "script src=\"" + base + path + "\"></" +
"script>");

Here's the voodoo. Why split "<script" into "<"+"script"? Likewise,
why split "></script>" into "></"+"script>"? In both cases, it appears
that the author doesn't think that a script may contain "<script" or
"</script". This is only (very) partly true. The only thing it cannot
contain is "</", but that is left unchanged.

A sufficiently escaped string expression is:
"<script src=\"" + base + path + "\"><\/script>"
And remember, you only need to escape "</" when it occurs inside
a script element in an HTML/XHTML page. If it is included as an
external file, there is no need to escape anything.

Good luck
/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[sundew]

Sadly, this doesn't work (please someone correct me if I'm wrong on
this). I've tried to do something like that before, so I could expose
only one global object (i.e. WS) and make all other properties
(WS.name), methods (WS.open()), and constructors (WS.WindowManager())
into members of that object. I couldn't get it to work. I haven't gone
so far as to read the ECMAScript spec with regard to this, but I'm
guessing that according to standard this sort of construct ( new
Identifier1.Identifier2() ) is not valid.

try this code:

<script language='Javascript'>
var WS = new Object();
WS.WednusManager = function(){
this.name = 'sample manager';
// more properties/methods and stuff
};

var myMan = new WS.WednusManager();
alert(myMan.name);
WS = null; // unload WS
</script

--
sunde
-----------------------------------------------------------------------
sundew's Profile: http://www.highdots.com/forums/member.php?userid=8
View this thread: http://www.highdots.com/forums/showthread.php?t=133064

[Random]

sundew wrote:

Sadly, this doesn't work (please someone correct me if I'm wrong on
this). I've tried to do something like that before, so I could expose
only one global object (i.e. WS) and make all other properties
(WS.name), methods (WS.open()), and constructors (WS.WindowManager())
into members of that object. I couldn't get it to work. I haven't gone
so far as to read the ECMAScript spec with regard to this, but I'm
guessing that according to standard this sort of construct ( new
Identifier1.Identifier2() ) is not valid.

try this code:

<script language='Javascript'>
var WS = new Object();
WS.WednusManager = function(){
this.name = 'sample manager';
// more properties/methods and stuff
};

var myMan = new WS.WednusManager();
alert(myMan.name);
WS = null; // unload WS
</script>
--
sundew

Hah. Figures -- I'd been trying to do it like this:

function Stuff() { return this }
Stuff.Thing = function () { return this };

x = new Stuff.Thing();
Never occurred to me to instantiate Stuff and use the method of the
resultant object to create a Thing.

function Stuff() { return this }

Stuff.prototype = {
constructor: Stuff,
Thing: function ( ) { return this; }
}

Stuff.prototype.Thing.prototype = {
constructor: Stuff.prototype.Thing
}

x = new Stuff();
y = new x.Thing();

alert( y.constructor === Stuff.prototype.Thing );
== True
Thanks!

[dna]

Hi Folks.

Ive been watching the wendus project grow for some time and it does
show the way for future web applications. The main focus here is
maximizing the performance and features of the underlaying
infrastructure to deliver a reliable and robust environment to the end
user. In english that means macking your stuff quick and easy to work
with.

I have spent the last five years developing an api that enables web
developers to build fully interactive sites with the minimum of code. I
seperate a 'sub-system of methods' from the main visible document in the
browser. I dont have to worry about how the sub-system works, just how
to program against it. This makes for easy site creation using advanced
features like windows, icons, images and text because you dont need to
worry about how they are created, you only need to know how to write
the simple code that calls the methods that generate these objects.

Having seen the code and how it is laid out I have to say
'nightmare!!!' Its not good, the visual effect and feel is first rate
but the code is a nightmare to administer and if you wanted to change
something you would have trouble.... Also the size of the codebase
could be a lot smaller and logically a lot more efficiant. Looking at
the lifespan of the codebase there could be a lot done to improve the
usability of the code. The idea is to write code once and use many
times and apply extrapalation into the equation and you could cut your
codebase by 60% or more....! Why repeat statments when you could wrap
them up and pass them variables instead..... The variable set the
parameters therefor you have only written that part of the code once
and used it many times, for example.... A simple image display method
could be written once say like img(id,w,h,t,l,b,z){30 lines of code
here!} and every time you need an image you write img(id,w,h,t,k,b,z);
this saves your writing the {30 lines of code here!} over and
over.....

The thing with programming for browsers is that no 2 are the same and
IE falls apart when trying to use complex mozilla script.... It is hard
to fit all sizes however sophisticated browser checking can help make
things more graceful when things go wrong....

Personally, you have taken on a difficult challenge my friend and you
are showing the way forward, industry is catching up quick and it wont
be long before these kind of net loaded operating systems will become
more common. The golden rule is to make things as simple as possible by
not over complicating the issue.

Keep it going....

Dna....

www.online-media-services.com
--
dna
------------------------------------------------------------------------
dna's Profile: http://www.highdots.com/forums/m1076
View this thread: http://www.highdots.com/forums/t1330649

[Sundew Shin]

Hi dna,
first of all, thank you for your time, and also I appreciate your
advise.

Having seen the code and how it is laid out I have to say
'nightmare!!!' Its not good, .... the code is a nightmare to
administer and if you wanted to change something you
would have trouble.... The thing with programming for browsers is that no 2 are the
same and IE falls apart when trying to use complex mozilla
script.... It is hard to fit all sizes however sophisticated browser
checking can help make things more graceful when things go
wrong....
Few days ago, I met Julie who is a software engineer in Google and
working for Gmail and Gmap team. We had a nice discussion mainly about
cross-browser support. She specifically showed her interest on the
fact that Wednus project supports most DOM supporting browsers
including KHTML-based browsers (Konqueror, Safari) and Opera without
looking up the navigator.userAgent property.
The source code of Wednus Window, for example, is browser-neutral, so
it has no single routine just for a specific browser type except one
place I refer the 'window.opera' for obtaining the more accurate
browser size for opera, but it'll be removed soon. (v0.3.6)
She also asked me what I would choose to do if I become known that a
new feature I want to add is showing inconsistency among 'minor'
browser types.
I said, "Then I don't implement the fancy new feature. But I don't
forget it."
And I also tell her, I could eventually implement all those features on
other days, of course with cross-browser support.

One very interesting fact I've learned in web application development
is that there are always multiple way to implement one specific feature
although it looks so atomic.
Making an image button with hover effect, for instance, can be
implemented many different ways. We all know there is onmouseover
event for Image object that we can listen, but I also can imagine that
it also could be done by constantly calculating the distance b/w the
image and the mouse pointer. If the horizontal distance is smaller
than the width of the image and vice versa for the vertical distance,
then it means the mouse is on the image.
I know using onmouseover or CSS styling is more elegant, but it's not
always the best especially when it shows different characteristic over
different browsers.
So, I can tell, not all of that 'nightmare' is redundant.

When it comes to the parts where assembling window components and
defining window methods, it is truly a nightmare to me as well.
Recently I have realized why we implement separate interface for a
class (or a sophisticated object). So I think the first part will
become organized as I apply the interface-core design style. And for
the second part, I've also got an idea to relate each window
component in organic manner, so they can react (repositioning/resizing)
for a certain event by themselves by calling each other recursively.
the size of the codebase could be a lot smaller
and logically a lot more efficient.. Why repeat
statments when you could wrap them up and pass
them variables instead...
The golden rule is to make things as simple as possible by
not over complicating the issue.

Some part, I am aware so working on it, but there is chance that I
don't aware the repeating of the code block for the specific part
(pattern) you may talk about. So it will be more than grateful if you
pin point the spots.

Again, thanks for your time and consideration, and I also have to say
what you have achieved at ' www.online-media-services.com ' is great.
I especially like the control-panel interface.
I wish I can get a chance to help you too. thanks, dna.