Re: [Dynapi-Dev] Suggestions

[Rob B. <rob...@ve...>]

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" <rob...@ve...>
> To: <dyn...@li...>;
> <dyn...@li...>
> 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" <ant...@gm...>
> > > To: <dyn...@li...>
> > > 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" <rob...@ve...>
> > > > >>To: <dyn...@li...>
> > > > >>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
> > > > >>>Dyn...@li...
> > > > >>>http://www.mail-archive.com/dyn...@li.../
> > > > >>>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>-------------------------------------------------------
> > > > >>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
> > > > >>Dyn...@li...
> > > > >>http://www.mail-archive.com/dyn...@li.../
> > > > >>
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > -------------------------------------------------------
> > > > > 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
> > > > > Dyn...@li...
> > > > > http://www.mail-archive.com/dyn...@li.../
> > > > >
> > > > >
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > 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
> > > > Dyn...@li...
> > > > http://www.mail-archive.com/dyn...@li.../
> > > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > 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
> > > Dyn...@li...
> > > http://www.mail-archive.com/dyn...@li.../
> > >
> >
> >
> >
> > -------------------------------------------------------
> > 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
> > Dyn...@li...
> > http://www.mail-archive.com/dyn...@li.../
> >
>
>
>
>
>
> -------------------------------------------------------
> 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
> Dyn...@li...
> http://www.mail-archive.com/dyn...@li.../