Seaside config for Comet (Seaside 2.9 A3)

>> The comet.js file depends on Scriptaculous, so the Scriptaculous
>> libraries must be loaded first in your app. This is not a problem when
>> using WAAdmin to register the app, but if you use the Seaside Config
>> tool, then the libraries are ordered in alphabetical order, putting
>> the Comet library first in the list. Comet won't load this way.
>
> This is not the case since Comet-Core-lr.31 anymore. I rewrote the
> Javascript support so that it can be used with Scriptaculous, JQuery,
> or any other Javascript library as you please:
>
>  Name: Comet-Core-lr.31
>  Author: lr
>  Time: 16 March 2009, 7:26:52 pm
>  UUID: 93bcab26-d9f2-43b5-b075-024893a0ca5a
>  Ancestors: Comet-Core-jf.30
>
>  - comet does not depend on prototype.js anymore
>  - rewrote the javascript side and fixed package dependencies
>
>> The solution is to use WAAdmin, but it would be nice if it were
>> possible to change the order of the libraries with the Config tool.
>
> That's a known issue, see
> <http://code.google.com/p/seaside/issues/detail?id=217>. We would
> really appreciate help to make the configuration interface better, and
> especially more user-friendly.
>
> Lukas
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

>> If the issue with the order of the libraries is just the UI, would it
>> be possible to add some JQuery Drag and Drop code to the pages?
>>    
>
> Exactly. Furthermore it would be cool if code for a given
> configuration could be automatically generated.
>
> The current configuration interface is really rigid and very much Web
> 1.0 style. It would be cool to make the configuration process much
> more interactive. In Seaside 2.9 we currently have 2 packages that
> provide an interface for the configuration, the traditional web based
> one and an new OmniBrowser based one. It would be great for newcomers
> to have a simple and visually appealing interface based on JQuery. We
> would be glad for help.
>
> Lukas
>  

> Lukas Renggli wrote:
>>> If the issue with the order of the libraries is just the UI, would it
>>> be possible to add some JQuery Drag and Drop code to the pages?
>>>
>>
>> Exactly. Furthermore it would be cool if code for a given
>> configuration could be automatically generated.
>>
>> The current configuration interface is really rigid and very much Web
>> 1.0 style. It would be cool to make the configuration process much
>> more interactive. In Seaside 2.9 we currently have 2 packages that
>> provide an interface for the configuration, the traditional web based
>> one and an new OmniBrowser based one. It would be great for newcomers
>> to have a simple and visually appealing interface based on JQuery. We
>> would be glad for help.
>>
>> Lukas
>>
> Why not throw the whole configuration interface out. It is completely
> unnecessary, and is a pain in the neck when it comes to deployment.
>
> MySite-#libraries
>
>    ^ #( SULibrary MyLibrary )
>
> That says all you need as far as which libraries are needed and in which
> order.
>
> Keith
>
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

> Keith,
> Respectfully, I disagree. I just started a few months ago with
> Seaside, and the configuration app helped me through some of the
> tutorials, I found on the web. Even some of the sample apps, Google
> charts for instance, require you to use the configuration app to get
> it working. I agree that once you know how to configure you own
> application, then doing it via a class method is the way to go.
> Documentation aside, its not obvious what is required to add support
> for the various libraries, and your own session objects etc.,
>  

> John Toohey wrote:
>> Keith,
>> Respectfully, I disagree. I just started a few months ago with
>> Seaside, and the configuration app helped me through some of the
>> tutorials, I found on the web. Even some of the sample apps, Google
>> charts for instance, require you to use the configuration app to get
>> it working. I agree that once you know how to configure you own
>> application, then doing it via a class method is the way to go.
>> Documentation aside, its not obvious what is required to add support
>> for the various libraries, and your own session objects etc.,
>>
> Hello John,
>
> lets give you a little hint of how this works in Beach (and Jetsam of old)
>
> there is method
>
> prefEnableCometHelper
>
> ^ false
>
> Now if you change that to true, comet is enabled, and you don't need any
> special session class.
>
> If you want to use ShoreComponents there is a method
>
> prefEableShoreHelper
>
> ^ false
>
> If you change that to true, you dont need any special session classes,
> you dont need to add any libraries, they are automatically added.
>
> The interface to the server WAKom etc can be set up to look at
> #prefEnableCometHelper, and it should know that a WAListener is required
> for that helper to work.
>
> You use code to write your whole application, and then when you move
> your image to the deployed machine you have to switch to using a config
> application in which half the settings need to be changed for
> deployment. So why put that conceptual and actual discontinuity of tools
> in there at all, its not as if these are even end user settings.
>
> The advantage of code is that it can embody the knowledge needed to set
> up the application. Dependencies between settings etc can be included.
> It could also include documentation about the settings and options
> available.
>
> You can also provide already working setups which can be adjusted via
> subclassing, why do you have to configure anything to use Google Charts?
>
> Keith
>>
>
>
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>