I would like to know if it's possible to add tooltips or in-page popups in my web site
using <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://script.aculo.us/" target="_blank">script.aculo.us.
And, if it's possible, how can i do that ?
Thanks, -- ------------------------------------------------------------ Gaëtan Le Brun 4 avenue Pierre Donzelot 35000 Rennes ------------------------------------------------------------ Email : [hidden email] Cell : +33 685 226294 ------------------------------------------------------------ _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
> I would like to know if it's possible to add tooltips or in-page popups in
> my web site using script.aculo.us. > And, if it's possible, how can i do that ? Yes, you can certainly do it. There is a basic example of something similar I hacked together in a few minutes on seasidehosting.st > support > account. There is no ready made solution coming with script.aculo.us, however quite a lot of people have actually written different kind of JavaScript extensions. Ask Google for "script.aculo.us tooltip". If you can come up with a nice integration into Seaside I would like to include that with the distribution. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Gaetan Le Brun
Before I spend a bunch of time that only duplicates the work of
others, I wanted to do a reality check. Is there anywhere a step-by-step recipe for how to get started and build a "core" Seaside Web app? I think I'm closing in on a process (there are probably lots of approaches, of course) based on reading Lukas Renggli's wonderful but necessarily sparse slide-based tutorial, and I'm about to test it by building my first from-scratch Seaside app this weekend. As a person is first a writer, then a coder, I tend to take careful notes during the development process with the idea that a written procedure might be helpful to others. But if this stuff is already done somewhere (if so, where?) or if it seems to the community like this is pretty obvious stuff and I'm beating a live seahorse (sorry for the mixed metaphor), I'll just go on my merry way. Seaside, by the way, is awesome! Dan _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Gaetan Le Brun
Before I returned to my Smalltalk roots, I took a side trip into Ruby
on Rails. I never got very good at it (I think maybe I'm too old to learn such fancy new tricks) but I did understand it conceptually and admired it. Seaside seems, in some ways, to be an improvement even on the wildly popular Rails. Except for one thing. One of the main things Rails does for you as a developer is completely abstract out the necessity of dealing with the database. And since most Web apps -- at least the ones I'm planning to build -- have databases behind them for one reason or another, this is kind of important. As far as I can tell, at least, Seaside leaves the issue unaddressed. Is that because Smalltalk apps are less likely to *use* databases or because of capabilities built into Squeak/Smalltalk that can be taken advantage of without having to put more code into Seaside or is it in the planning stages or what? Dan _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Dan Shafer-3
>
> Before I spend a bunch of time that only duplicates the work > of others, I wanted to do a reality check. > > Is there anywhere a step-by-step recipe for how to get > started and build a "core" Seaside Web app? I think I'm > closing in on a process (there are probably lots of > approaches, of course) based on reading Lukas Renggli's > wonderful but necessarily sparse slide-based tutorial, and > I'm about to test it by building my first from-scratch > Seaside app this weekend. As a person is first a writer, then > a coder, I tend to take careful notes during the development > process with the idea that a written procedure might be > helpful to others. > > But if this stuff is already done somewhere (if so, where?) > or if it seems to the community like this is pretty obvious > stuff and I'm beating a live seahorse (sorry for the mixed > metaphor), I'll just go on my merry way. > > Seaside, by the way, is awesome! > > Dan Even if someone else had already done it, I'm sure no one would mind another tutorial. Please share anything you have with the community, documentation is always welcome. _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Dan Shafer-3
> another, this is kind of important. As far as I can tell, at
> least, Seaside leaves the issue unaddressed. Is that because > Smalltalk apps are less likely to *use* databases or because > of capabilities built into Squeak/Smalltalk that can be taken > advantage of without having to put more code into Seaside or > is it in the planning stages or what? > > Dan Bingo.... you can run directly on the image and never "need" a database at all, rails wouldn't work without a database. Even when using a database, object databases tend to be par for the course, rather than relational, so it still feels like running right out of the image and the db stuff is out of the way. _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Ramon Leon wrote:
>> another, this is kind of important. As far as I can tell, at >> least, Seaside leaves the issue unaddressed. Is that because >> Smalltalk apps are less likely to *use* databases or because >> of capabilities built into Squeak/Smalltalk that can be taken >> advantage of without having to put more code into Seaside or >> is it in the planning stages or what? >> >> Dan >> > > Bingo.... you can run directly on the image and never "need" a database > at all, rails wouldn't work without a database. Even when using a > database, object databases tend to be par for the course, rather than > relational, so it still feels like running right out of the image and > the db stuff is out of the way. > different types of data, large quantity of data, and a good backup system. Am I wrong in thinking this? Let's say you need to store audio data and/or video data. This can become quite large. What architecture are you suggesting when you recommend object dBs? brad _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Dan Shafer-3
hey dan,
i agree. i played a little bit with the Magma database which has a nice integration abillity with seaside. have a look at swiki to get more info. but the sophistication and (DOCUMENTATION!!!) that for example the OODB db4o brings for java (especially Web Apps) isn`t reached by far. i see that most people who are developing these amazing extensions and applications with and for squeak see only few pennies (or none at all) for the work they do. but without proper and a kind of more recent documentation newbies get interested but won`t stay because they get lost too easily. thats why i turned backed to java (jsf) several times. at the moment i only consider to hold any kind of data in the image itself. an improvement on the navigational structure and organization of documentation on swiki could do wonders. any thoughts? a bit off topic : i am sorry for that. ... Am 01.06.2006 um 18:31 schrieb Dan Shafer: > Before I returned to my Smalltalk roots, I took a side trip into > Ruby on Rails. I never got very good at it (I think maybe I'm too > old to learn such fancy new tricks) but I did understand it > conceptually and admired it. Seaside seems, in some ways, to be an > improvement even on the wildly popular Rails. Except for one thing. > > One of the main things Rails does for you as a developer is > completely abstract out the necessity of dealing with the database. > And since most Web apps -- at least the ones I'm planning to build > -- have databases behind them for one reason or another, this is > kind of important. As far as I can tell, at least, Seaside leaves > the issue unaddressed. Is that because Smalltalk apps are less > likely to *use* databases or because of capabilities built into > Squeak/Smalltalk that can be taken advantage of without having to > put more code into Seaside or is it in the planning stages or what? > > Dan > > _______________________________________________ > Seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Dan Shafer-3
> Still, it seems that a separate dB would provide a nice way
> of accessing different types of data, large quantity of data, > and a good backup system. > Am I wrong in thinking this? Let's say you need to store > audio data and/or video data. This can become quite large. > > What architecture are you suggesting when you recommend object dBs? > > brad Personally, I use Goods, check out the following tutorials on the matter... http://www.shaffer-consulting.com/david/Seaside/SeasideAndGOODS/ http://www.techgame.net/projects/Seaside/wiki/UsingGOODS There is also, OmniBase, and Magma. Goods and Magma are server based, OmniBase is file based. I never quite got OmniBases tamed for Seaside due to it's multiversion concurrency control and sharing objects between transactions, but I know others have. Magma worked great, as simple as Goods, but was too new at the time; I chose Goods instead. Things may have changed since then. _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Ramon Leon wrote:
>> Still, it seems that a separate dB would provide a nice way >> of accessing different types of data, large quantity of data, >> and a good backup system. >> Am I wrong in thinking this? Let's say you need to store >> audio data and/or video data. This can become quite large. >> >> What architecture are you suggesting when you recommend object dBs? >> >> brad >> > > Personally, I use Goods, check out the following tutorials on the > matter... > http://www.shaffer-consulting.com/david/Seaside/SeasideAndGOODS/ > http://www.techgame.net/projects/Seaside/wiki/UsingGOODS > > There is also, OmniBase, and Magma. Goods and Magma are server based, > OmniBase is file based. I never quite got OmniBases tamed for Seaside > due to it's multiversion concurrency control and sharing objects between > transactions, but I know others have. Magma worked great, as simple as > Goods, but was too new at the time; I chose Goods instead. Things may > have changed since then. > brad _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Dan Shafer-3
I'm not sure whether the complete abstraction is only a positive
thing. The fact that RoR just "does it for you" may be nice for demos and simple apps but if your needs get more complex you want to have some sort of control. I don't know RoR well, but from what I saw it does not seem to support tweaking the automatically generated code because round trips cannot be handled (you just loose your changes the next time you change the DB schema and generate the code). Seaside does not deal with persistency at all. I think that's a good, after all, it is a web application framework. You are free to use whatever persistency solution which works best for you. If you need something that lets you go fast I suggest you to try GOODS or Magma, which are very transparent concerning what you have to deal with when writing your app. For a relational DB (e.g., Postgres), the ROE framework is interesting... Cheers, Adrian On Jun 1, 2006, at 18:31 , Dan Shafer wrote: > Before I returned to my Smalltalk roots, I took a side trip into > Ruby on Rails. I never got very good at it (I think maybe I'm too > old to learn such fancy new tricks) but I did understand it > conceptually and admired it. Seaside seems, in some ways, to be an > improvement even on the wildly popular Rails. Except for one thing. > > One of the main things Rails does for you as a developer is > completely abstract out the necessity of dealing with the database. > And since most Web apps -- at least the ones I'm planning to build > -- have databases behind them for one reason or another, this is > kind of important. As far as I can tell, at least, Seaside leaves > the issue unaddressed. Is that because Smalltalk apps are less > likely to *use* databases or because of capabilities built into > Squeak/Smalltalk that can be taken advantage of without having to > put more code into Seaside or is it in the planning stages or what? > > Dan > > _______________________________________________ > Seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Brad Fuller
Brad,
go for Magma, you will have your life a lot easier than with OmniBase. Petr Brad Fuller wrote: > Ramon Leon wrote: >>> Still, it seems that a separate dB would provide a nice way >>> of accessing different types of data, large quantity of data, >>> and a good backup system. >>> Am I wrong in thinking this? Let's say you need to store >>> audio data and/or video data. This can become quite large. >>> >>> What architecture are you suggesting when you recommend object dBs? >>> >>> brad >>> >> Personally, I use Goods, check out the following tutorials on the >> matter... >> http://www.shaffer-consulting.com/david/Seaside/SeasideAndGOODS/ >> http://www.techgame.net/projects/Seaside/wiki/UsingGOODS >> >> There is also, OmniBase, and Magma. Goods and Magma are server based, >> OmniBase is file based. I never quite got OmniBases tamed for Seaside >> due to it's multiversion concurrency control and sharing objects between >> transactions, but I know others have. Magma worked great, as simple as >> Goods, but was too new at the time; I chose Goods instead. Things may >> have changed since then. >> > Thanks for the pointers. I'll check them out. > brad _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Adrian Lienhard
Adrian Lienhard wrote:
> I'm not sure whether the complete abstraction is only a positive thing. > The fact that RoR just "does it for you" may be nice for demos and > simple apps but if your needs get more complex you want to have some > sort of control. Whether or not it can handle more complex needs, it's a marketing goldmine, and an easy entry point for newcomers. > On Jun 1, 2006, at 18:31 , Dan Shafer wrote: >> One of the main things Rails does for you as a developer is >> completely abstract out the necessity of dealing with the database. >> ... or is it in the planning stages or what? Working on it, but stalled due to paying gig (non-ST). Currently, I can "scrape" the postgres schema to yield the classes, and a simple form-based interface. The next step, would be to infer the relationships from either foreign key constraints or field naming conventions. I'm hoping this will be enough attract and hold newcomers. _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Adrian Lienhard
Actually, RoR deals very nicely and cleanly with database versioning
and tracking. Schema changes can be handled and managed directly in Ruby code in Rails. On Jun 1, 2006, at 12:32 PM, Adrian Lienhard wrote: > I don't know RoR well, but from what I saw it does not seem to > support tweaking the automatically generated code because round > trips cannot be handled (you just loose your changes the next time > you change the DB schema and generate the code). Dan _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Lukas Renggli
On 5/31/06, Lukas Renggli <[hidden email]
> wrote:
> I would like to know if it's possible to add tooltips or in-page popups in There is no ready made solution coming with <a href="http://script.aculo.us/" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> script.aculo.us, however I found Tooltip.js on <a href="http://tooltip.crtx.org/" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://tooltip.crtx.org/, it is based on Prototype and <a href="http://script.aculo.us" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
script.aculo.us.
you can come up with a nice integration into Seaside I would like to I would like to try to integrate it in seaside but I don't know how to integrate Cheers,Javascript in Seaside. Could you give some clues to do that ? -- ------------------------------------------------------------ Gaëtan Le Brun 4 avenue Pierre Donzelot 35000 Rennes ------------------------------------------------------------ Email : [hidden email] Cell : +33 685 226294 ------------------------------------------------------------ _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
> I would like to try to integrate it in seaside but I don't know how to
> integrate > Javascript in Seaside. > > Could you give some clues to do that ? This should actually be quite simple You need to pack Tooltip.js into a WAScriptLibrary sublclass and add it to your application (like Scriptaculous). Then you just need to create divs with the class tooltip. http://tooltip.crtx.org/index.php?page=HowItWorks Give me a moment and I'll hack a demo together. Cheers Philippe _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
> Give me a moment and I'll hack a demo together.
http://squeaksource.com/seachart/Tooltip-pmm.1.mcz - Create a new application with TTDemo as the root component. - Add SUScriptLibrary - Add TTScriptLibrary It's a bit buggy, and does have no CSS at all. You can take it as a starting point. Cheers Philippe _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Thanks Philippe,
I will test it as soon as possible.
On 6/2/06, Philippe Marschall <[hidden email]> wrote:
> Give me a moment and I'll hack a demo together. -- ------------------------------------------------------------ Gaëtan Le Brun 4 avenue Pierre Donzelot 35000 Rennes ------------------------------------------------------------ Email : [hidden email] Cell : +33 685 226294 ------------------------------------------------------------ _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Yanni Chiu
Thanks to everyone who replied to my original query.
I suspect that OmniBase may turn out to be best for my purposes. But there is some confusion about its licensing. I've written the author an email; hopefully I'll hear back soon. I've read in the archives of this list that a commercial license is $400. That's affordable in my case. However, his Web site doesn't even mention a commercial product as far as I can tell. His site at least conveyed to me the impression that he has a single product, it's free, and you pay for support. If I understand his support plan correctly, it costs almost $600 because he charges a minimum of 8 hours. That's OK but if that's per-incident, of course, it won't work, at least for me. If someone on the list knows the answer, I'd appreciate hearing it. Otherwise, when I do hear from the OmniBase author, I'll report what I hear. Dan _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
It took a while to track it down, but in the comments on squeaksource
for OmniBase-jf.2.mcz: "OmniBase is now available for free for commercial and educational purposes. Free version of OmniBase is prohibited to be used in the oil or military industries." On 6/3/06, Dan Shafer <[hidden email]> wrote: > Thanks to everyone who replied to my original query. > > I suspect that OmniBase may turn out to be best for my purposes. But > there is some confusion about its licensing. I've written the author > an email; hopefully I'll hear back soon. > > I've read in the archives of this list that a commercial license is > $400. That's affordable in my case. However, his Web site doesn't > even mention a commercial product as far as I can tell. His site at > least conveyed to me the impression that he has a single product, > it's free, and you pay for support. If I understand his support plan > correctly, it costs almost $600 because he charges a minimum of 8 > hours. That's OK but if that's per-incident, of course, it won't > work, at least for me. > > If someone on the list knows the answer, I'd appreciate hearing it. > Otherwise, when I do hear from the OmniBase author, I'll report what > I hear. > > Dan > > _______________________________________________ > Seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Free forum by Nabble | Edit this page |