dynapi-dev — List related to the current DynAPI Core development

Re: [Dynapi-Dev] Some fixes for src/gui/graphics.js

[Leif W <war...@us...>]

Hello,

I'm trying to clean out some old changes.  I came across this.  I made
the changes previously but did not submit.  I had probably gotten
distracted.

I have updated the example to draw (line, circle, rectangle, ellipse),
and fill (circle, rectangle and ellipse).  However, something about the
ellipse fill code is not right.  It tends to make my browser use all the
CPU and not respond.  While not the fastest machine, it's far from the
slowest, running an AMD Athlon XP 2700+.  JavaScript code should never
kill a browser's CPU.  ;-)  Certainly not on a CPU at this speed.

Furthermore, the "delete last" and "delete all" is unimplemented.  I
could not determine how best to approach this.  I attempted to destroy
all children.  At the document level, it removes the Graphics layer as
well as it's children.  On the layer level, the function was not
defined, which I could not understand.  For specific examples of my
pitiful attempts, see the example source code.

In addition, there were "drawOval" and "fillEllipse" method names.  I
found this to be inconsistent and confusing so I made the first
"drawEllipse", then added aliases for "drawOval" and "fillOval", for
backwards compatibility and ease of use.

I would like to submit the example code and the library code, get any
other fixes or suggestions, and then if it's agreed that the name
changes are clearer, I'd like to update the documentation and complete
this little bugfix in a comprehensive manner.  Actually, I just looked,
and there is no documentation for Graphics, or the contents of
graphics.js.  If someone could suggest which naming structure to use,
and which fileto use as a template, I will create the documentation for
this object, at least for the portions I understand.  ;-)

Reference files:

dynapi3x/docs/docs/quickref.gui.graphics.html ?
dynapi3x/examples/dynapi.gui.graphics.html
dynapi3x/src/gui/graphics.js

Leif

----- Original Message ----- 
From: "Andrew Gillett" <an...@zo...>
To: <dyn...@li...>
Sent: Wednesday, March 31, 2004 7:15 PM
Subject: Re: [Dynapi-Dev] Some fixes for src/gui/graphics.js


>   Hi Leif,
>
> My suggested changes do make a difference.
>
> Try making the following changes to examples/dynapi.gui.graphics.html.
> Change line 25 from:
>     graphics.setFillColor(lyr.bgcolor);
> to:
>     graphics.setFillColor('green');
>
> and change line 36 from:
>     graphics.drawCircle(...
> to
>     graphics.fillCircle(...
>
> This should cause the "draw circle" button to draw filled green
> circles.  WIthout my changes it doesn't work because the
> Graphics.setFillColor() method is not setting the same variable that
the
> Graphics.fillCircle() method uses.
>
>
> Andrew.
>
>
> Leif W wrote:
>
> >Hi!  I've made changes to my local copy and played with the example
page.
> >Can't see any difference, but the example is very simple (draw line,
circle,
> >and rectangle - yes I added a rectangle to the example -- button was
there
> >but onclick was empty -- which I'll upload to CVS later).  Do you
have any
> >more complex example pages up with the two different
src/gui/graphics.js
> >files, which reveal the bugs caused by the forgotten relics?
> >
> >Leif
> >
> >----- Original Message ----- 
> >From: "Andrew Gillett"
<an...@zo...><dyn...@li...>
> >To: "dynapi-dev"
> >Sent: Thursday, March 25, 2004 12:18 AM
> >Subject: [Dynapi-Dev] Some fixes for src/gui/graphics.js
> >
> >
> >
> >
> >>Hi,
> >>
> >>I was looking at some of  the graphics functions (dynapi 3)
> >>and there are some simple errors.  It looks like some variables
> >>were renamed at some point, but the old variable names were
> >>not all cleaned up.  Perhaps someone can commit the changes
> >>below to CVS?
> >>
> >>The correct variable names are:
> >>_s   StrokeColor (was color)
> >>_w  StrokeWeight (was thickness)
> >>_f    FillColor (was color)
> >>
> >>
> >>Andrew.
> >>
> >>
> >>49c49
> >><       fillCircle(x+r,y+r,r,this.color,this._dlyr);
> >>---
> >> >       fillCircle(x+r,y+r,r,this._f,this._dlyr);
> >>52c52
> >><
>
>>drawEllipse(x+w/2,y+h/2,w,h,this.color,false,this.thickness,this._dlyr
);
> >>---
> >> >
drawEllipse(x+w/2,y+h/2,w,h,this._s,false,this._w,this._dlyr);
> >>55c55
> >><
>
>>drawEllipse(x+w/2,y+h/2,w,h,this.color,true,this.thickness,this._dlyr)
;
> >>---
> >> >
drawEllipse(x+w/2,y+h/2,w,h,this._f,true,this._w,this._dlyr);
> >>58c58
> >><       drawRect(x,y,w,h,this.color,this.thickness,this._dlyr);
> >>---
> >> >       drawRect(x,y,w,h,this._s,this._w,this._dlyr);
> >>61c61
> >><       fillRect(x,y,w,h,this.color,this._dlyr);
> >>---
> >> >       fillRect(x,y,w,h,this._f,this._dlyr);
> >>
> >>
> >>
> >>
> >>
> >>-------------------------------------------------------
> >>This SF.Net email is sponsored by: IBM Linux Tutorials
> >>Free Linux tutorial presented by Daniel Robbins, President and CEO
of
> >>GenToo technologies. Learn everything from fundamentals to system
>
>>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> >>_______________________________________________
> >>Dynapi-Dev mailing list
>
>>Dyn...@li...http://www.mail-archive.com/dynapi-dev
@lists.sourceforge.net/
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> >-------------------------------------------------------
> >This SF.Net email is sponsored by: IBM Linux Tutorials
> >Free Linux tutorial presented by Daniel Robbins, President and CEO of
> >GenToo technologies. Learn everything from fundamentals to system
> >administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> >_______________________________________________
> >Dynapi-Dev mailing list
>
>Dyn...@li...http://www.mail-archive.com/dynapi-dev@
lists.sourceforge.net/
> >
> >
> >
> >
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://www.mail-archive.com/dyn...@li.../
>
>

[Dynapi-Dev] Bug in groupmanager.js

[Andrew G. <an...@zo...>]

Hi,

I've come across a small but annoying bug in the groupmanager...

In groupmanager.js, there is a function called "_NewSetLocation" which 
is used to override the DynLayers "setLocation" function.  "setLocation" 
is called from DynLayer.setX like so:
    p.setX=function(x) {this.setLocation(x,null)};
i.e. with one argument set to null.

When setX() or setY() is called on a layer that is managed by the 
groupmanager, the groupmanagers NewSetLocation function tries to 
calculate how far the layer has moved :
    GroupManager._NewSetLocation = function(x,y){
         var byX=x-this.x;
         var byY=y-this.y;
So, if you call setX(), it will calculate the byX value correctly but 
will set the byY value to "-this.y". This has the effect of setting the 
x-coord of the layer to what you want and setting the y-coord to 0!  A 
few tests to see int the x or y values are null seems to fix things up 
nicely.

A fixed version is:
    GroupManager._NewSetLocation = function(x,y){
         var byX=0,byY=0;
         if(x!=null) byX=x-this.x;
         if(y!=null) byY=y-this.y;


Andrew.

Re: [Dynapi-Dev] Bug in htmlradiobutton.js

[Leif W <war...@us...>]

Without looking at the code, the example would be clearer if it said
"Red Car" for the "Red" option, and "Blue Car" for the "Blue" option.
It would also be clearer if it mentioned somewhere that I was picking
the color of a "Car".  ;-)

Before any changes:

  * In Mozilla Firefox 0.9 and Opera 7.50, I get "Blue Car" for "Red"
option, and nothing for "Blue" option.

  * In IE 6, I get "Red Car" for "Red" option, and nothing for "Blue"
option.

I made the suggested changes, and added a listener for "optblue".

After the changes:

  * Mozilla Firefox 0.9, Opera 7.50 and IE 6 work correctly; alerted
colors correspond to button labels.

I'll go ahead and submit these changes to CVS.

Leif

----- Original Message ----- 
From: "Andrew Gillett" <an...@zo...>
To: <dyn...@li...>
Sent: Friday, July 16, 2004 2:19 AM
Subject: [Dynapi-Dev] Bug in htmlradiobutton.js


> Hi,
>
> I recently tried using the HTMLRadioButton widget and found that while
> it worked under IE6, it was quite broken on Mozilla/Firebird.
>
> If you look at the example,
> dynapi3x/examples/dynapi.gui.htmlradiobutton.html, when you click on
the
> "Red" radio button you'll get an popup that says "Red Car" on IE but
> says "Blue Car" on Mozilla.  It should say "Red Car" on both.
>
> A quick look at the constructor for this class shows on line 15:
>     this._elmId = elmName||('Radio_'+this._group);
> The "elmName" is not supplied to the constructor (at least in the
> example), and given that the element id should always be unique, I
have
> changed the line to:
>     this._elmId = elmName||(this.id+'Radio');
> - this is similar to what is in htmlcheckbox.js.
>
> And on line 65, I changed the name of the radio button group from
> "this._elmId" to "this._group":
>     return '<input type="radio"   ...  +'" name="'+this._elmId+  ...
> becomes:
>     return '<input type="radio"  ...  +'" name="'+this._group+'  ...
>
>
> This change seems to work quite well on both IE and Mozilla, so if
there
> is a committer out there who is willing to commit this fix, that would
> be good.
>
>
> Andrew.
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://www.mail-archive.com/dyn...@li.../
>

[Dynapi-Dev] Bug in htmlradiobutton.js

[Andrew G. <an...@zo...>]

Hi,

I recently tried using the HTMLRadioButton widget and found that while 
it worked under IE6, it was quite broken on Mozilla/Firebird.

If you look at the example, 
dynapi3x/examples/dynapi.gui.htmlradiobutton.html, when you click on the 
"Red" radio button you'll get an popup that says "Red Car" on IE but 
says "Blue Car" on Mozilla.  It should say "Red Car" on both.

A quick look at the constructor for this class shows on line 15:
    this._elmId = elmName||('Radio_'+this._group);
The "elmName" is not supplied to the constructor (at least in the 
example), and given that the element id should always be unique, I have 
changed the line to:
    this._elmId = elmName||(this.id+'Radio');
- this is similar to what is in htmlcheckbox.js.

And on line 65, I changed the name of the radio button group from 
"this._elmId" to "this._group":
    return '<input type="radio"   ...  +'" name="'+this._elmId+  ...
becomes:
    return '<input type="radio"  ...  +'" name="'+this._group+'  ...


This change seems to work quite well on both IE and Mozilla, so if there 
is a committer out there who is willing to commit this fix, that would 
be good.


Andrew.

Re: [Dynapi-Dev] Suggestions

[Doug M. <do...@cr...>]

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" <rob...@ve...>
To: <dyn...@li...>
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" <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.../
>
>
>
> -------------------------------------------------------
> 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.../
>


---
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

Re: [Dynapi-Dev] Suggestions

[Doug M. <do...@cr...>]

AS far as modifying the style to "standardize" the dynapi..
This is a task custom made for me.. one of the biggest part of
my job the manipulation of large amounts of dissimilar data..

I'm sure I could automate to process for the most part..

----- Original Message ----- 
From: "Leif W" <war...@us...>
To: <dyn...@li...>
Sent: Thursday, June 10, 2004 12:35 PM
Subject: Re: [Dynapi-Dev] Suggestions


> 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.../
> 


---
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

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.../

Re: [Dynapi-Dev] Suggestions

[Leif W <war...@us...>]

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.../
>

Re: [Dynapi-Dev] Suggestions

[Doug M. <do...@cr...>]

yeah outlook express when combined with a virus scanner can send blank
messages.. it really sucks i tell ya..

----- Original Message ----- 
From: "Peter Romianowski" <ant...@gm...>
To: <dyn...@li...>
Sent: Thursday, June 10, 2004 12:55 PM
Subject: Re: [Dynapi-Dev] Suggestions


> 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"-notatio
n 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" <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.../
>


---
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/04

Re: [Dynapi-Dev] Suggestions

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

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" <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.../
> 
> 

Re: [Dynapi-Dev] Suggestions

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

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 <war...@us...> 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
>>
> 
> === 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
> Dyn...@li...
> http://www.mail-archive.com/dyn...@li.../
> 
> 

Re: [Dynapi-Dev] Suggestions

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

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.../
> 

Re: [Dynapi-Dev] Suggestions

[Leif W <war...@us...>]

Yeah, any way you look at it, there's some work to do to achieve better
docs.  :p  Just trying to understand the situation and weigh the
uptions.

Leif

----- Original Message ----- 
From: "Peter Romianowski" <ant...@gm...>
To: <dyn...@li...>
Sent: Thursday, June 10, 2004 11:56 AM
Subject: Re: [Dynapi-Dev] Suggestions


> 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.../
> >
> >
>
>
> -------------------------------------------------------
> 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.../
>
>

Re: [Dynapi-Dev] Suggestions

[Leif W <war...@us...>]

Right, shorter, ok.  So that saves us a few bytes on downloads, at the
cost of easy to manage documentation, and slightly more cluttered code?
Is there any additional penalty besides larger file and verbose code?
For instance, will having longer names slow down the JavaScript engines
on browers?  The transfer of extra bytes are probably negligible in
comparison to all the images that are likely to be transferred, and
would probably barely add up to a single image in most cases.  If
someone used many or most (up to all) available DynAPI code, how much
bigger might we be talking?  MB bigger?  Percentage bigger than using
the same options with the shorthand "p."?

Leif

----- Original Message ----- 
From: "Raymond Irving" <xw...@ya...>
To: <dyn...@li...>
Sent: Thursday, June 10, 2004 11:42 AM
Subject: Re: [Dynapi-Dev] Suggestions


>
> "p." is much shorter than "classname.prototype."
>
> 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?
>
>
> __
> Raymond Irving
>
>
> --- Leif W <war...@us...> 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
> >
> === 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
> Dyn...@li...
> http://www.mail-archive.com/dyn...@li.../
>

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.../
> 
> 

Re: [Dynapi-Dev] Suggestions

[Raymond I. <xw...@ya...>]

"p." is much shorter than "classname.prototype."

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?


__
Raymond Irving


--- Leif W <war...@us...> 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
> 
=== message truncated ===

Re: [Dynapi-Dev] Suggestions

[Doug M. <do...@cr...>]

---
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/04

Re: [Dynapi-Dev] Suggestions

[Leif W <war...@us...>]

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.../
>

Re: [Dynapi-Dev] Suggestions

[Doug M. <do...@cr...>]

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.../
>

Re: [Dynapi-Dev] Suggestions

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

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.../
> 
> 

Re: [Dynapi-Dev] Suggestions

[Leif W <war...@us...>]

Hi,

I'm not familiar at all with the Ant project, but I am familiar with
Apache by itself, for most common things.  I'm not a huge fan of Java at
all, nor am I fan of using one language for everything, but I am a fan
of having everything in as many languages as possible, and to that
degree, have no objection to Java, but think it's a good idea.  To me,
that is true "portability" of a high-level package, to run in any
high-level language, which has interpreters or compilers for every
platform.  Some may cry "maintenance nightmare", but it doesn't phase
me.

About Perl, it uses something called POD (Plain Old Documentation),
which is an extremely simplistic syntax which can exist simultaneously
with Perl code in the same file.  The Perl interpreter or compiler
ignore POD, and POD ignores Perl code.  There are converters such as
pod2man and pod2html (and a few other formats) which extract and format
the POD from the source file.  However, there is no template.  It is
hard-coded into pod2man and pod2html (etc.), and basically only creates
a simplistic UNIX man page or HTMLized man page.

One would have to create a parser that either reinvents the (POD) wheel
entirely, implementing a template system and introducing more hooks for
fields and custom formatting, or create a parser that can parse the
stock HTML output, but require that the coder leave comments formatted
very carefully so that they can be post-processed.  The first is a
cleaner solution, but involves more work, and duplicates some
functionality that already exists, and will no longer be tied to the
stock POD parser, so any changes to the stock POD parser or syntax would
have to be duplicated, which incurs a slight maintenance fee, or else
lock the POD syntax we use and require coders to use a potentially older
syntax.  The second solution may break at any time if the behaviour of
the stock POD parser changes, but might be quicker to implement at
first, and might not be subjected to the same maintenance fee, but
things could still break if the POD parser changed, regardless of the
same syntax freeze.  With that said, it's not really expected that POD
changes too much or anything anyways.  ;-)

And this is just to cover the JavaScript and Perl code.  I think for a
project like ours with multiple languages, it would be desireable to
have a universal comment parsing engine, which can use the same
templates, so that all documents generated look more or less the same.
Plugins would be used for extracting the actual comments, with fields
labelled to act as special hooks for formatting and organizing
information about variables, functions, objects, etc..

I do not think a strict JavaDoc style would suit every language.  Each
language has their own quirks.  Trying to make comments from a C program
look like they're object oriented probably wouldn't work too well.  Perl
has some things it calls packages, which may or may not also be objects,
which again, may or may not also be classes, depending on how it is
coded and what version of Perl is in use.  Furthermore, some code which
uses the package, may also be using plain functions, object method
calls, or fully fledged class calls, depending on the syntax used in
both the package and the calling script.  Perl also has no such thing as
a private, public, or protected variableor method calls in object
oriented programming (design philosophy: "Stay out of my living room,
not because I have a shotgun, but because you weren't invited.", it's up
to the users of an object not to go poking around where they do not
belong, using intentionally undocumented internal variables, which
allows the object programmer to document an interface, yet change the
internals at will.).  That's not to say that variables can't be
protected very well by the programmer (at a slight performance cost)
using such a thing as a "closure" in Perl.  But detecting if code
contains a closure, and then calling it "protected" or "private", and
similar detections, would be too much for a comment parser to try and
determine all of this based on code interpretation.  Then the effort to
analyze the source would be greater than the output of documentation,
and would probably be very error prone.

That said, I have nothing against the JavaDoc format.  For Java, I think
it's excellent.  The Perl POD is lackluster by comparison.  There may
already be Perl modules addressing all these issues in CPAN, so it may
not be as hard as I imagine to get POD comments from a Perl source, and
generate JavaDoc-like documentation.  I will research when I have the
time.

Quite busy at the moment, with some oldie upgrades and vintage
overclocking.  (From 486 to Socket  7 to Super 7 to Slot A to Socket A,
my first 5 mainboards).  Catching up on 7 years of upgrades and
overclocking in a week has been insane.  Getting all the research done
and obtaining the vintage parts has been maddening.  Getting things
working and doing stability and performance tests and taking
measurements for empirical data is going to be interesting.  Trying out
the 3-dozen mostly undocumented DIP settings for an old PNY Quickchip,
and stabalizing and benchmarking each working setting is going to be
gruelling.  Documenting all my research should prove challenging; I'll
have to make archives of literally dozens if not hundreds of web pages
and images, since they always seem to have gone down when you go looking
for them in a year (links to original sites incase they are still alive,
or still maintained too).  The results, will be put on a personal web
site and hopefully be enlightening for someone stupid enough (erm) to
undertake some old upgrades.

Leif

----- Original Message ----- 
From: "Rob Butler" <rob...@ve...>
To: <dyn...@li...>;
<dyn...@li...>
Sent: Thursday, June 10, 2004 8:52 AM
Subject: Re: [Dynapi-Dev] Suggestions


> 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 ove
> r 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.../
>

Re: [Dynapi-Dev] Suggestions

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

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.../
> 

Re: [Dynapi-Dev] Suggestions

[Leif W <war...@us...>]

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.../
>

[Dynapi-Dev] Suggestions

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

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

Re: [Dynapi-Dev] DynAPI Updates

[Raymond I. <xw...@ya...>]

And while we are on the topic of server-side projects... Here's a cool server-side project that some of you guys might be interested in:
 
http://www.gotdotnet.com/Community/Workspaces/workspace.aspx?id=69b08b15-d456-4cf9-8b12-d4642ef0c22e
 
__
Raymond Irving


Leif W <war...@us...> wrote:
My 2 cents. Version 4 browsers are retarded and should die.
Governments or Militaries with big bureaucracies are always antiquated.
If they want to use 10-20 year old software, they pay the consequences
and let the rest of the world make progress. If you want it to work in
a version 4 or less browser, do everything on the server side via CGI.
Leave all static content. Or (cringe) use applets or Flash. :p But
the same government people probably restrict the use of either.

Sorry, no offense Doug. It's gotto suck to be responsible for
supporting old software for a technologically antiquated employer, be
they government, military, educational institution, or big business. I
know I would personally refuse to work under such conditions and find
another job, even if it meant leaving the country and going half way
around the world.

Leif

----- Original Message ----- 
From: "Doug Melvin" 
To: 
Sent: Wednesday, June 02, 2004 10:46 AM
Subject: Re: [Dynapi-Dev] DynAPI Updates


> Yeah, uh, About NS4..
> Any of you administer a web server?
> I host 5 sites.. Apone the monthly processing of the logs
> you do see that 15 to 20% of visitors to these five sites
> are still using NS4.. (and 2% using NS3!!!)
>
> While I do agree that supporting NS4 is a serious pain in the
> backside, I have to tell you that the government standards in Canada
> still call for support 4X borwsers. And what with the government being
the
> single larges employer in Canada, that's a pretty big user base (and
the
> source of ALL
> of my work)
>
> Just my 2 cents.
>
> cheers
>
>
> ----- Original Message ----- 
> From: "Kevin" 
> To: 
> Sent: Tuesday, June 01, 2004 9:51 AM
> Subject: Re: [Dynapi-Dev] DynAPI Updates
>
>
> >
> > "Raymond Irving" wrote:
> >
> > > Hello Everyone,
> > >
> > > It has been a long time since I've updated my copy of
> > > DynAPI much less to say update the CVS. Well things
> > > are still rolling along as I can see that there's a
> > > lot of emails to read :)
> > >
> > > I've managed to setup my new website and I've uploaded
> > > my local copy of the DynAPI for everyone to review:
> > >
> > > http://www.xwisdomhtml.com
> >
> > Nice site. It's been a long time since I've looked at DynAPI.
> > I'll have a look at dynapi3x.zip and the new widget design if I
> > get some time.
> >
> > > I would like for all to review the changes and test ni
> > > NS4. The new widgets might not be 100% compatible with
> > > NS4 (sorry guys, I have a warm time trying to get the
> > > Boxfix to work in NS4) :{
> >
> > As someone who was always keen on NS4 compatibility when
> > some operating systems were delivered with NS4 - now I don't
> > think that this the case. I'm now using Redhat Linux 9 which is
> > not shipped with NS4. Sorry I can't help with NS4 testing.
> >
> > So I wouldn't worry if new DynAPI developments don't support
> > NS4. Unless someone can cite an OS shipping with NS4?
> >
> > > Here are some of the changes that I've made thus far:
> > >
> > > * New widget design (no longer use StyleManager)'
> > > * New RichTextBox widget (beta)
> >
> > That RichTextBox widget looks very neat.
> >
> > Kevin
> >
> > > * Boxfix implemented
> > >
> > > Enjoy and please give you feedback.
> > >
> > > __
> > > Raymond Irving
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.Net email is sponsored by: Oracle 10g
> > > Get certified on the hottest thing ever to hit the market...
Oracle 10g.
> > > Take an Oracle 10g class now, and we'll give you the exam FREE.
> > > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> > > _______________________________________________
> > > Dynapi-Dev mailing list
> > > Dyn...@li...
> > > http://www.mail-archive.com/dyn...@li.../
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: Oracle 10g
> > Get certified on the hottest thing ever to hit the market... Oracle
10g.
> > Take an Oracle 10g class now, and we'll give you the exam FREE.
> > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> > http://www.mail-archive.com/dyn...@li.../
> >
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.693 / Virus Database: 454 - Release Date: 5/31/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
> 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.../