Hi again,
"p." is much shorter than "classname.prototype."
Was my first intention too. And since each file usually contains only class
this is ok for me in terms of readybility.
I think it was more for saving space than anything
On another note:
Can I now update CVS with the copy that I have? Did
you download and test the code from
www.xwisdomhtml.com?
I downloaded it and played with it (going through the examples). I cannot easily
drop it into my codebase because I changed quite a lot in my copy of the dynapi.
Our project schedule says that in july there will be a slot for extending / refactoring
our DHTML-frontend. Then I will try to merge our codebase with the dynapi (adopting
the new style-stuff and contributing some changes if useful for others).
For me it would be best if there would be an up-to-date CVS-version or even a release
by then.
Some quick notes after playing around:
- The widgets look great!
- The Richtext-Box only works in IE?? Funny enough: I recently wrote a Richtext-Editor
for our application. ;) Since it is highly integrated I cannot contribute it, but if
needed I could add mozilla-support to the existing one.
BTW: For advanced features take a look at the HTMLArea.
Another question: What kind of notation are you using? Why is the methodname "Render"
capitalized?
Finally, besides saying that the examples worked and I like the new style-design, I
really
cannot do any more testing now :|
Raymond, do
Regards
Peter
__
Raymond Irving
--- Leif W <[EMAIL PROTECTED]> wrote:
What was the basis of the original decision to use
"p" instead of the
"standard" way? Was it for performance? Was it
before there was a
standard? If it's for performance, it might not be
good to change it in
the release code. But could development code be
written in standard
format, then be converted to use "p" everywhere for
production via some
util? Would it bee too insane to approach it this
way? Is there a
better way?
Leif
----- Original Message -----
From: "Doug Melvin" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 10, 2004 10:58 AM
Subject: Re: [Dynapi-Dev] Suggestions
YEs! let's get a cvs update!
There have been a few fizes as of late.
As for the prototyping, switching it over to the
"standard" way would
now be
too difficult..
(i don't think) I could dedicate myself to that
conversion, but
someone will
have to commit it
(i have been trying to get sourceforge to sent me
my damned password
for 3
years now, maybe it's fixed now?)
cheers
----- Original Message -----
From: "Peter Romianowski" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 10, 2004 10:12 AM
Subject: Re: [Dynapi-Dev] Suggestions
Hi,
just some short comments on JsDoc.
I am using JsDoc for quite a while now and it
works well for me. But
using
it for the (current)
dynapi codebase brings a lot of problems because
of the way dynapi
handles
to definition of classes.
JsDoc only "accepts" classes (prototypes)
written the "standard"
way:
function MyClass() {
}
// Superclasses must be defined like this
MyClass.prototype = new MySuperClass();
// Methods like this:
MyClass.prototype.myFunction=function() {
}
The "dynapi way" is this:
function MyDynapiClass() {
// Inheritance (I think JsDoc recognizes
this too)
this.MyDynapiSuperClass=MyDynapiSuperClass;
this.MyDynapiSuperClass();
}
var p = dynapi.setPrototype ('MyDynapiClass',
'MyDynapiSuperClass');
p.myFunction=function() {
}
The problem is that methods are declared using
the "p-variable".
This way
JsDoc does not regocnize
the class-methods. One would have to patch JsDoc
or rewrite the
dynapi...
Generelly I really like the idea of using JsDoc
(I use it ;) This
leads to
much cleaner code and helps
a lot understanding the code (because it
includes comments then).
>> Of course, you still have
>> to comment your code at some level, which
takes time, energy and
>> discipline. :p
But it buys you a lot! I remember the pain I had
understanding the
dynapi
completely. There are concepts
(the "old" Stylemanager, SODA) that are really
not so easy to
understand
in the first place. Missing documentation
makes it even harder.
As soon as the "new" DynAPI 3.0 is in CVS I
really would like to
contribute some of my extension and help out
in documentation. Perhaps(!) I will have a
deeper look into JsDoc to
extend it. The idea of a Java-based
javascript-javadoc is great. If someone has the
time starting such a
project I would be a happy contributer
to it! ;) Perhaps looking at Rhino
(http://www.mozilla.org/rhino/)
or
another Java-based JS-Interpretor could
help here...
Just my 2 cents,
Peter
Rob Butler wrote:
Hey Leif,
Nice to (virtually) meet you.
I don't think that JSdoc will parse / JavaDoc
anything but
Javascript at
this point. But similar tools could possibly be
built for those other
languages. Other people who use those languages
all the time may
already
have done that. But if we at least get the Dynapi
Javascript code
Javadoc'd
that would be a good thing, since it's the lion's
share of the code,
and
what people are going to use the most.
JSdoc uses a Perl templating framework, so if
need be the
templates
could be modified to perform custom output / html
generation. I would
say
to use them as they are initially and modify the
templates later as
Dynapi
needs. The JSdoc tool seems to build a collection
of object tree
structures
that contain all the information about the code.
Then the collection
of
object tree structures are used in the templates
to generate the HTML.
This
is great because after the parsing stage all the
collected info is
available
for use in any way you want during the html
generation stage in the
templates.
If JSdoc were re-done in Java (again
preferably as an ant task) I
would
suggest using either Velocity or Freemarker as a
templating framework
to do
the same thing as the Perl templating framework.
The "port" to Java
could
probably be done in a few parts & stages. One
part would work on
getting a
Java version of the parsing system that builds the
collection of tree
=== message truncated ===
-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the
one installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://www.mail-archive.com/[EMAIL PROTECTED]/
-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the
one installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://www.mail-archive.com/[EMAIL PROTECTED]/
