Hi,
Would switching over to the "standard" way of prototyping and method definition be too difficult because:
The term "standard way of prototyping" is misleading here. (Even though I might
have introduced it ;) Doing
it the dynapi-way is completely legal and widely used, though the "standard" way is
more readable.
1) It's just a lot of boring monotonous work
It definitely is! ;)
or
2) The internals of Dynapi depend on doing prototyping and method declaration this way
I think the only line that is really needed for dynapi to work is:
dynapi.setPrototype('Button','Widget');
The rest is shortcut. In my own widgets I always use the
"MyClass.prototype.myFunction=function(){}"-method
even for subclasses of dynapi-classes. So it works.
or
3) some other reason (performance, etc.)
I cannot imagine any performance impact by using either way.
If it's only because it's a lot of boring work then we could potentially convert the
codebase to the "standard way", as long as the entire codebase doesn't need to be
changed at once. I.E. can we change it one class at a time and still have everything work ok.
This would be better than making changes to the JSdoc tool to support Dynapi's "way" of doing things.
>It would buy us two things: 1) Dynapi would use the standard, and it's generally a
good thing to be
>standardized. 2) It would allow JSdoc to generate the javadoc without us needing to
modify it.
As said before the changes to JsDoc would be minimal. Of course I would like to get
the changes into the
JsDoc itself not just our copy of it. BTW the lack of the "dynapi"-notation is a bug
in JsDoc anyway. There
are many programmers using shortcuts like this - not only dynapi.
I definetly want to build a Java & ant based javascript compressor and javascript javadoc tool.
>I think these are definetly needed and would be used by the community. So let's
pursue doing that.
I am very eager to see this happen and will help you out!
On another note, instead of using CVS what about subversion?
The dynapi-project is hosted at sourceforge.net. I don't know if they provide a
subversion-installation.
Oh, the last two messages from Doug appeared to have no content except for the messages added by the mailing systems. Am I the only one that got those that way, or did Doug send two empty messages?
;) This happens from time to time. I thought he fixed it ;)
Regards
Peter
Later
Rob
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
structures. The other part would work on re-creating the Perl templates in
Velocity or Freemarker. The conversion of the templates would probably be
fairly easy... Just take the Perl templates and convert the syntax for
substitution to use the velocity/freemarker syntax instead of the Perl
syntax. Of course before doing that we would have to get permission from
the JSdoc developers if we wanted to use a different license than GPL. If
we did all this work to build an ant task to JavaDoc JavaScript it would be
good if we did it under and Apache license, as then it could be incorporated
into Ant itself. The
ant group could potentially take over development / maintainance at that
point too, since it could / would become part of Ant's core.
Later
Rob
PS. Paragraphs -- They're a good thing. :)
Hmm, I'm only a half-peon contributor but I think I remember hearing
about or looking at the jsdoc project. Wouldn't that be cool, to just
be bumping along in your code, modifying things and dropping some
comments, and click a button and generate new docs that are up to date?
That would really combat the doc lag problem. Of course, you still have
to comment your code at some level, which takes time, energy and
discipline. :p Sounds like a good idea though, and something I could
help with, if only involved moving text from the current docs back into
the source. But I might not know if the docs are /correct/. That could
be easily tackled as a separate problem though, first convert, then
correct. Ideally it'd be done in one go. But if it takes the first
step to motivate someone to do the second step, then it'd be worth it in
the end IMO. But, eh, what about custom formatting of the webpages and
such? Can the JSDoc treat comments as sort of a "database" entry,
allowing tokens and their values to be assigned to variables, and then
use templates to replace with the variables and values? And what about
the ASP (JScript and VBScript), Perl, PHP, (TCL, Scheme, Java, etc.)
sources for the server-side scripts like IOElement and SODA? Can JSDoc
support other comment structures, like Perl's '#'?
Leif
----- Original Message -----
From: "Rob Butler" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, June 09, 2004 9:27 PM
Subject: [Dynapi-Dev] Suggestions
Hello,
Dynapi 3.0 looks real nice. I hope to use it in a variety of open
source &
commercial projects that I will be developing shortly. I hope to
contribute
back to the Dynapi project as well. On that front I have a few
suggestions.
I really like having a Javascript compressor and it's great to see you
have
implemented one in Java. It would be great if the compressor could be
extended to be an ant task as well as a stand alone executable.
Instead of
just wrapping the existing Java class as an ant task, I would
recommend
building the ant task to work in the "ant way" in that it doesn't use
a
separate config file, and accepts parameters & settings from the ant
script.
If I get some spare time between my other projects I could potentially
help
with this, but I just wanted to get the thought out there if someone
else
wanted to run with it.
Regarding the Javascript compressor, I think it's pretty neat how you
have
it doing runtime inclusion / exclusion of scripts in a single file
instead
of needing to pull in multiple smaller files. However, I think the
larger
file size is probably more of a negative than the separate small
files.
Browsers are pretty well optimized for pulling in lots of little files
because everything on the web is a separate small file. I just point
this
out because if an ant based Javascript compressor were built I think
this
feature could be left out without too much of a negative impact
compared to
the existing applications featureset.
Like most open source projects the documentation in Dynapi seems to be
lagging the code's capabilities. I was considering developing my own
API
similar to Dynapi (thanks for saving me a ton of work) and knew
documentation would be difficult to keep up with, and being a Java
developer
I really like JavaDoc. So I looked for a Javascript Javadoc tool and
found
one: http://jsdoc.sourceforge.net/ This tool is written in Perl
(which is
ok, I would just prefer Java so it could be an Ant task without
wrapping a
separate perl module). Perhaps Dynapi could adopt using this tool to
document it's internals? I would also be interested in developing a
Java
based ant task to do Javascript Javadoc generation. Perhaps if you
all
think it is a good idea to use this tool, we could contact the JSDoc
developers and see if they would be interested in developing a Java
port of
their tool as an ant task. Perhaps JSDoc & Dynapi could join forces
since
both groups are obviously interested in Javascript, and both have
developed
a Javascript "build time" tool that compliment each other?
Just some thoughts. Looking forward to doing good things with /
contributing to Dynapi.
Later
Rob
-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://www.mail-archive.com/[EMAIL PROTECTED]/
-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://www.mail-archive.com/[EMAIL PROTECTED]/
-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://www.mail-archive.com/[EMAIL PROTECTED]/
-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org
_______________________________________________
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]/
-------------------------------------------------------
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]/
