Re: [Dynapi-Dev] Suggestions

[Peter R. <ant...@gm...>]

Hi,

I think the better way would be to stick to the "p"-thing and modify JsDoc.
(or (later) rewrite JsDoc in Java or whatever) The should be easy enough
because JsDoc uses a bunch of regexp.

Converting the dynapi would be hell! ;)

Regards
Peter

Leif W 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" <do...@cr...>
> To: <dyn...@li...>
> 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" <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.../
> 
>