agreed.
Changing the var p's should be easy..
I would do it right this moment, but do not have the lastest fixes..
or would you guys rather I just do it then merge your code it?
I have a light day sceduled so let me know..
----- Original Message -----
From: "Rob Butler" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 10, 2004 9:37 PM
Subject: Re: [Dynapi-Dev] Suggestions
> It would appear that #3 is a non-issue, which is good. Number 1 can
easily
> be solved with a good amount of grunt work. A really quick search on the
> Dynapi source (everything under "src/*.*") showed 1122 references to "p."
in
> 84 files. So it shouldn't be too large of an effort to convert the
method's
> to use the "standards".
>
> If most files only contain one class we could probably employ search and
> replace on the file and then fix the one or two places that won't work.
For
> example in the dynlayer_base.js file if we searched on "p." and did a
> replace of "DynLayer.prototype", and then changed line 48 which is:
>
> var p = dynapi.setPrototype('DynLayer','DynElement');
> to
> DynLayer.prototype = dynapi.setPrototype('DynLayer','DynElement');
>
> Would the class / file still work? If this were true in most files then
we
> could be done quickly with "standardizing" the method declaration. This
> operation for example wouldn't take long at all, and would handle 52
> references to "p." in 1 file. One person could do the conversion in a
> night.
>
> As for the need to use setPrototype we could potentially modify JSdoc to
> pick this up as the extension, OR we could create another javadoc tag of
> "@extends" to use either in the javadoc of the sub-classes constructor, or
> just above the setPrototype call of the sub-class. This may be easier
> because JSdoc was designed to allow adding custom "@xyz" javadoc tags.
This
> would then require the developer to be a good person and actually use the
> "@extends" tag, but the entire purpose of using a javadoc like system is
to
> be a good developer and keep the doc's up to date and correct, so it's not
> that much of a stretch.
>
> What do you think?
>
> Later
> Rob
>
> > Doug is known to have a misbehaving Lookout Opressed client. I have a
> > Lookout Opress too, but it seems to behave, luckily.
> >
> > Good questions btw. It's what I had in my head but didn't get into
> > words.
> >
> > Ways to approach the the first of the three problems:
> >
> > 1) Boring, monotonous work: divide and conquer? If the problem can be
> > modularized, we can divide and conquer. Additionally it could maybe be
> > made fun by creating a simple web-page tracking system for updates
> > (statuses: open, in progrgess, complete), and the top 1, 3 or 5
> > contributors get some prize, like an online gift certificate or
> > something? Anything to get it done. Now I just need a backer or
> > co-backer... :p
> >
> > Don't have any good ideas for the 2nd or 3rd.
> >
> > Leif
> >
> > ----- Original Message -----
> > From: "Rob Butler" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>;
> > <[EMAIL PROTECTED]>
> > Sent: Thursday, June 10, 2004 12:14 PM
> > Subject: Re: [Dynapi-Dev] Suggestions
> >
> >
> > > Would switching over to the "standard" way of prototyping and method
> > definition be too difficult because:
> > >
> > > 1) It's just a lot of boring monotonous work
> > > or
> > > 2) The internals of Dynapi depend on doing prototyping and method
> > declaration this way
> > > or
> > > 3) some other reason (performance, etc.)
> > >
> > > 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. It would probably be easier to modify Dynapi
> > than JSdoc anyway.
> > >
> > > 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.
> > >
> > > On another note, instead of using CVS what about subversion?
> > Subversion has been released as a 1.0 and is much better than CVS,
> > especially when you want to do refactoring, etc.
> > >
> > > 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?
> > >
> > > 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]/
>
>
>
> -------------------------------------------------------
> 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]/
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.703 / Virus Database: 459 - Release Date: 6/10/2004
-------------------------------------------------------
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]/
