Menu
▾
▴
Re: [Dynapi-Dev] Suggestions
|
From: Peter R. <ant...@gm...> - 2004-06-10 16:43:08
|
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.../ > > |
