<div class="gmail_quote">On Sat, May 16, 2009 at 12:35 AM, Lukas Renggli <span dir="ltr"><<a href="mailto:renggli@gmail.com">renggli@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">> Hi, I was wondering, what was the rationale for creating a single package<br>
> for Prototype and <a href="http://script.aculo.us" target="_blank">script.aculo.us</a>.<br>
<br>
</div>Yeah, that bothered me a bit as well. The combination has historical reasons.<br>
<div class="im"><br>
> Most times I tend to use Prototype without <a href="http://script.aculo.us" target="_blank">script.aculo.us</a>. I'm asking<br>
> this question because I'm concerned<br>
> about loading stuff that I will not use in production (i.e. lean<br>
> deployment environment).<br>
<br>
</div>In practice this is no big deal though. If you just use the prototype<br>
functionality there is no problem just to include prototype.js with<br>
your deployed application.<br></blockquote><div><br></div><div>Yes, this sounds doable to me because I really don't want to be loading</div><div>un-needing components. Seaside provide a mechanism to automatically</div>
<div>generate the API when these components are included in the head tag?</div><div>For example, if a new stable release is published with a new and/or </div><div>modified API, would these new additions be added to Seaside's interface</div>
<div>for this component?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
A possible way of doing this is by including<br>
"<a href="http://ajax.googleapis.com/ajax/libs/prototype/1.6.0.3/prototype.js" target="_blank">http://ajax.googleapis.com/ajax/libs/prototype/1.6.0.3/prototype.js</a>"<br>
into the HTML HEAD, instead of adding the file library that contains<br>
<div class="im">Prototype and <a href="http://script.aculo.us" target="_blank">script.aculo.us</a>.<br>
<br>
</div>Now that we have a common infrastructure for Javascript support in<br>
Seaside 2.9 it would probably make sense to split the Scriptaculous<br>
package. There is also a jQuery and jQuery-UI package that can be<br>
loaded separately and that play a similar role as Prototype and<br>
<a href="http://script.aculo.us" target="_blank">script.aculo.us</a>.<br>
<br>
The only concern I have about splitting the Scriptaculous package is<br>
that people will be confused and that code needs to be migrated. If<br>
anybody has an idea of a clean way of doing this, please let me know.<br>
<div class="im"></div></blockquote><div><br></div><div>I personally really don't think they would be confused anymore than someone</div><div>who's using these packages outside of Seaside 2.9. I would even say that </div>
<div>the Seaside 2.9 Package Builder does an excellent job including the associated</div><div>dependencies for a given component. </div><div><br></div><div>It would be great if I can click a Seaside component and select update without </div>
<div>destroying the image. At time time, I was informed that I would need to use an</div><div>image that doesn't have Seaside in it. It's like creating a new document each time </div><div>you add a new paragraph to it. Will this be resolved in the future?</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><br>
> Next, I'm curious about the naming of the test for their associated<br>
> components. Thus, is it a convention to<br>
> name the tests "<component-name-prefix>-Tests-<component-name-suffix>? Did<br>
> the development team<br>
> consider the following:<br>
> <component-name>-Tests<br>
<br>
</div><component-name-prefix> is the poor-mens namespace, that we require to<br>
avoid name conflicts until all Smalltalk's support some sort of a<br>
compatible namespace implementation.<br>
<br>
Mhh, now I am confused. Are you referring to Seaside 2.8 or Seaside<br>
2.9? Are you referring to class names or package names?<br></blockquote><div><br></div><div>Yes, I was referring to Seaside 2.9 and their package names.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
If you refer to package naming in Seaside 2.9 the conventions are<br>
given here: <<a href="http://code.google.com/p/seaside/wiki/PackageNaming" target="_blank">http://code.google.com/p/seaside/wiki/PackageNaming</a>>.<br>
Sticking to exactly that scheme is important in Pharo and Squeak,<br>
because packages are defined using category prefixes.<br></blockquote><div><br></div><div>Thanks for the information and I really appreciate it.</div><div><br></div><div>-Conrad</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Lukas<br>
<font color="#888888"><br>
--<br>
Lukas Renggli<br>
<a href="http://www.lukas-renggli.ch" target="_blank">http://www.lukas-renggli.ch</a><br>
_______________________________________________<br>
seaside-dev mailing list<br>
<a href="mailto:seaside-dev@lists.squeakfoundation.org">seaside-dev@lists.squeakfoundation.org</a><br>
<a href="http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev" target="_blank">http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev</a><br>
</font></blockquote></div><br>