Hi all,
I have done a simple template system for Seaside: http://homepage.mac.com/alain_fischer/mc/SeasideTemplate-AFi.1.mcz This is probably full of bugs but I am using it and it seem to work well.
Prerequisite: - Seaside - SmaCC
How to use it: Make your components subclass of SSTComponent. The template can be embeded or external - embeded: create a method templateString in your component - external: create a file templates/MyComponent.sst.html The format of templates is html text with smalltalk code between "<?sst" and "?>" Html text is translated as: html text: 'my html text'. Smalltalk code is simply copied.
Known issue: - Parsing of template are slow, but since they are cached in an autogenerated method this is not a big problem. I will see how to improve parsing speed with SmaCC rather than writing a custom parser.
Enjoy using this. Alain
On 28/gen/04, at 12:43, Alain Fischer wrote:
Hi all,
I have done a simple template system for Seaside: http://homepage.mac.com/alain_fischer/mc/SeasideTemplate-AFi.1.mcz This is probably full of bugs but I am using it and it seem to work well.
Prerequisite:
- Seaside
- SmaCC
How to use it: [...]
It should be interesting to compare it with nori. someone has done it? In my own opinionm nori looks good but it uses xml as input.
I'd like to have (x)html as input, possibly even a quite bad html (not xhtml validated, like html 3.2...). What are your experience? Ciao ciao!
HI Giovanni,
First a small precision, Nori use XML as input this include XHTML.
I have tried Nori first and found that it doesn't respond to my need in one of our project. The page where in HTML not XHTML, Nori as I understand it is based on manipulating XML DOM which I found not very easy.
In this project, we must display customer designed HTML page with embeded data from an oodb (GOODS). The customer page are modified often and all I have said is that they must not modified what is between "<?sst" and "?>" and till now after several modification nothing bad appened.
SeasideTemplate was simply modeled based on the smalltalk methods I have written before I have done this template system. In fact it could be seen as some kind of macro for writting smalltalk.
Have a nice day. Alain
Le 22 févr. 04, à 15:28, Giovanni Giorgi a écrit :
On 28/gen/04, at 12:43, Alain Fischer wrote:
Hi all,
I have done a simple template system for Seaside: http://homepage.mac.com/alain_fischer/mc/SeasideTemplate-AFi.1.mcz This is probably full of bugs but I am using it and it seem to work well.
Prerequisite:
- Seaside
- SmaCC
How to use it: [...]
It should be interesting to compare it with nori. someone has done it? In my own opinionm nori looks good but it uses xml as input.
I'd like to have (x)html as input, possibly even a quite bad html (not xhtml validated, like html 3.2...). What are your experience? Ciao ciao! -- [ [ [ JJ ] ] ] | Il mio gatto non e' in bianco e nero, | e' a colori. http://www.siforge.org JJ Rotating signatures....
Seaside mailing list Seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/seaside
On Feb 22, 2004, at 6:59 AM, Alain Fischer wrote:
In this project, we must display customer designed HTML page with embeded data from an oodb (GOODS).
I'm curious - have you looked yet at data structures for large collections and indexes? It seems to me we're going to need to find or write some kind of BTree class to reduce the number of objects that get pulled in when doing lookups - certainly the stock Squeak Dictionary class is not optimal. Since there are a number of people suddenly starting to use GOODS, we may want to jointly look at building this stuff. The GOODS Java client has some code we could probably steal implementation strategies from...
Avi
On Monday 23 February 2004 1:08 pm, Avi Bryant wrote:
On Feb 22, 2004, at 6:59 AM, Alain Fischer wrote:
In this project, we must display customer designed HTML page with embeded data from an oodb (GOODS).
I'm curious - have you looked yet at data structures for large collections and indexes? It seems to me we're going to need to find or write some kind of BTree class to reduce the number of objects that get pulled in when doing lookups - certainly the stock Squeak Dictionary class is not optimal. Since there are a number of people suddenly starting to use GOODS, we may want to jointly look at building this stuff. The GOODS Java client has some code we could probably steal implementation strategies from...
Just use the BerkeleyDB.
Ned Konz ned@squeakland.org wrote:
On Monday 23 February 2004 1:08 pm, Avi Bryant wrote:
On Feb 22, 2004, at 6:59 AM, Alain Fischer wrote:
In this project, we must display customer designed HTML page with embeded data from an oodb (GOODS).
I'm curious - have you looked yet at data structures for large collections and indexes? It seems to me we're going to need to find or write some kind of BTree class to reduce the number of objects that get pulled in when doing lookups - certainly the stock Squeak Dictionary class is not optimal. Since there are a number of people suddenly starting to use GOODS, we may want to jointly look at building this stuff. The GOODS Java client has some code we could probably steal implementation strategies from...
Just use the BerkeleyDB.
IIRC Magma has stuff like this.
regards, Göran
On Feb 23, 2004, at 2:59 PM, goran.krampe@bluefish.se wrote:
IIRC Magma has stuff like this.
I don't believe Magma has a BTree implementation. It does have some special large collection classes, but they're tied to Magma; I'm looking for something more generic.
At any rate, I've just started writing one myself... I'll be committing something working (inserts and retrieves, anyway, no deletes yet) sometime tonight. Help (additional tests, optimizations, whatever) would be welcome.
You can track my progress at http://beta4.com/mc, package 'Collections-BTree'. I'm going from some course notes I found here: http://www.cs.umbc.edu/~woodcock/cmsc341/btree/defn.html .
Avi
Avi Bryant avi@beta4.com wrote:
On Feb 23, 2004, at 2:59 PM, goran.krampe@bluefish.se wrote:
IIRC Magma has stuff like this.
I don't believe Magma has a BTree implementation. It does have some special large collection classes, but they're tied to Magma; I'm looking for something more generic.
Maybe you are right. Just looked and couldn't see anything.
At any rate, I've just started writing one myself... I'll be committing something working (inserts and retrieves, anyway, no deletes yet) sometime tonight. Help (additional tests, optimizations, whatever) would be welcome.
You can track my progress at http://beta4.com/mc, package 'Collections-BTree'. I'm going from some course notes I found here: http://www.cs.umbc.edu/~woodcock/cmsc341/btree/defn.html .
Avi
Neat. And another sidenote: slate has tree collections.
regards, Göran
Avi Bryant ha scritto in data 24/02/2004 8.22:
On Feb 23, 2004, at 2:59 PM, goran.krampe@bluefish.se wrote:
IIRC Magma has stuff like this.
I don't believe Magma has a BTree implementation. It does have some special large collection classes, but they're tied to Magma; I'm looking for something more generic.
Yes. I am using magma and it seems not having this ADT :( BTW, using Magma I feel the lack of a minimal query language. For example, I cannot get all the contact which the name is John, ordered by surname. I can use only an index to get all the John contact-s, and then I must order them manually (=using a SortedCollection). GOODS can do it better? You experience? ;))
On Feb 24, 2004, at 2:08 AM, Giovanni Giorgi wrote:
Yes. I am using magma and it seems not having this ADT :( BTW, using Magma I feel the lack of a minimal query language. For example, I cannot get all the contact which the name is John, ordered by surname. I can use only an index to get all the John contact-s, and then I must order them manually (=using a SortedCollection). GOODS can do it better?
No, GOODS is very like Magma in this respect - you have to build your own indices. Just as you would if you weren't using a database at all, but had everything in the image.
On Feb 23, 2004, at 2:30 PM, Ned Konz wrote:
Just use the BerkeleyDB.
No, the idea is not to have a btree implementation that accesses the filesystem directly, but to have an object equivalent that is suitable for distributed objects or remote OODB systems. So instead of optimizing how many disk blocks you need to access, the idea is to optimize how many object instances you have to touch (and if you have variable sized instances involved, how big they are).
No for the moment, my largest data collection is between 50 and 100 objects and I haven't had performance problems. The others objects are already organized as tree.
But sure if we need to store bigger collection we will need something with better performance, BTree is a good candidate.
Alain
On 23 févr. 04, at 22:08, Avi Bryant wrote:
On Feb 22, 2004, at 6:59 AM, Alain Fischer wrote:
In this project, we must display customer designed HTML page with embeded data from an oodb (GOODS).
I'm curious - have you looked yet at data structures for large collections and indexes? It seems to me we're going to need to find or write some kind of BTree class to reduce the number of objects that get pulled in when doing lookups - certainly the stock Squeak Dictionary class is not optimal. Since there are a number of people suddenly starting to use GOODS, we may want to jointly look at building this stuff. The GOODS Java client has some code we could probably steal implementation strategies from...
Avi
Seaside mailing list Seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/seaside
On Feb 24, 2004, at 2:17 AM, Alain Fischer wrote:
No for the moment, my largest data collection is between 50 and 100 objects and I haven't had performance problems. The others objects are already organized as tree.
But sure if we need to store bigger collection we will need something with better performance, BTree is a good candidate.
Göran points out that Skiplists would be good candidates as well. I had momentarily overlooked this because for some reason the Squeak SkipList implementation doesn't provide a Dictionary protocol, but instead acts like a SortedCollection (does anyone know the reason for this?). I'll probably end up building them both to compare.
Avi
I wasn't knowing the existance of Squeak SkipList. So, I googled and found that: - Scott A Crosby refactoring with Dictionary protocol
http://lists.squeakfoundation.org/pipermail/squeak-dev/2002-February/ 035066.html - A paper on SkipList implementation http://citeseer.nj.nec.com/cache/papers/cs/1389/ftp: zSzzSzftp.cs.umd.eduzSzpubzSzpaperszSzpaperszSzncstrl.umcpzSzCS-TR -2286.1zSzCS-TR-2286.1.pdf/pugh90skip.pdf
I think that Scott A Crosby implementation is what you want
Alain
On 24 févr. 04, at 11:33, Avi Bryant wrote:
On Feb 24, 2004, at 2:17 AM, Alain Fischer wrote:
No for the moment, my largest data collection is between 50 and 100 objects and I haven't had performance problems. The others objects are already organized as tree.
But sure if we need to store bigger collection we will need something with better performance, BTree is a good candidate.
Göran points out that Skiplists would be good candidates as well. I had momentarily overlooked this because for some reason the Squeak SkipList implementation doesn't provide a Dictionary protocol, but instead acts like a SortedCollection (does anyone know the reason for this?). I'll probably end up building them both to compare.
Avi _______________________________________________ Seaside mailing list Seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/seaside
On Feb 24, 2004, at 2:50 AM, Alain Fischer wrote:
I wasn't knowing the existance of Squeak SkipList. So, I googled and found that:
- Scott A Crosby refactoring with Dictionary protocol
http://lists.squeakfoundation.org/pipermail/squeak-dev/2002-February/ 035066.html
- A paper on SkipList implementation
http://citeseer.nj.nec.com/cache/papers/cs/1389/ftp: zSzzSzftp.cs.umd.eduzSzpubzSzpaperszSzpaperszSzncstrl.umcpzSzCS-TR -2286.1zSzCS-TR-2286.1.pdf/pugh90skip.pdf
I think that Scott A Crosby implementation is what you want
Aha, perfect. So tomorrow I can compare that with my BTree code.
But first I need to get some sleep.
;) Avi
I spent some of today doing benchmarking of various data structures with GOODS. The main run off I ended up being interested in was Dictionary vs. my new BTree implementation. For small collections you definitely want Dictionary. For large collections, what it comes down to is how big your transactions are - there's an inherent overhead to using a Dictionary (because it has one huge array of associations), and if your transactions are fairly small that can have a huge cost, particularly when inserting.
Here are some times for transactions involving retrieving or inserting various numbers of items into a Dictionary or a BTree in a GOODS database already loaded with 50,000 string keys. They all also include the overhead of starting a new connection to GOODS.
Dictionary - retrieve 1: 6s - insert 1: 16s - retrieve 100: 9s - insert 100: 24s - retrieve 1000: 45s - insert 1000: 82s
BTree - retrieve 1: 1.5s - insert 1: 1.5s - retrieve 100: 22.5s - insert 100: 13.5s - retrieve 1000: 143.5s - insert 1000: 49s
My guess is that the BTree would show a greater advantage for remote databases (this was connecting to a DB on localhost), since the Dictionary has to transfer more bytes. OTOH, it would also be interesting to try a Dictionary with one of the LargeArray implementations, which would solve the major problem.
I did do some testing with Scott Crosby's SkipList implementation, but in general it showed similar characteristics to the BTree with a higher constant factor. I'll test it more when I have more time.
Incidentally probably the most important thing I found out was that allocating new objects in GOODS one by one is horrendously slow; there's an undocumented bulk allocation mechanism that I'll need to add support for ASAP.
Avi
On Feb 22, 2004, at 9:59 AM, Alain Fischer wrote:
HI Giovanni,
First a small precision, Nori use XML as input this include XHTML.
Correct. The design of Nori is such that it's possible to add other parsers to support other formats. Since I want my apps to produce compliant XHTML, I never found a need for a straight HTML parser. I wouldn't be hard to add, though. I suspect Julian's HTML parser would be easy to adapt.
I have tried Nori first and found that it doesn't respond to my need in one of our project. The page where in HTML not XHTML, Nori as I understand it is based on manipulating XML DOM which I found not very easy.
Yes. Nori is based on applying Lisp-style lexical macros to the XHTML DOM.
It's a bit different from most template systems, so it does take some getting used to, like Seaside its self. I've found that it requires both less Smalltalk code and less coupling between the code and the template. OTOH, you do have to learn the protocol exposed by the DOM, since the standard Smalltalk string manipulation library isn't used.
In this project, we must display customer designed HTML page with embeded data from an oodb (GOODS). The customer page are modified often and all I have said is that they must not modified what is between "<?sst" and "?>" and till now after several modification nothing bad appened.
Aha! This is indeed a trade off.
Nori was designed to maximize separation between the template and the code, so that designers could work independently from coders. I think it does this quite well, but it does require some discipline and knowledge on the part of the designers - they have to write well-formed XHTML (unless someone implements an HTML parser) and they have to understand Nori macros well enough to use them correctly.
A system like Stephen's Smalltalk Server Pages, or SeasideTemplate (if I understand correctly), doesn't give the designer as much freedom or independence from the programmer, but it also doesn't require them to know anything about the templating system.
SeasideTemplate was simply modeled based on the smalltalk methods I have written before I have done this template system. In fact it could be seen as some kind of macro for writting smalltalk.
That sounds interesting. I'll have to take a closer look at SeasideTemplate.
Colin
seaside@lists.squeakfoundation.org
-
Alain Fischer -
Alain Fischer -
Avi Bryant -
Colin Putney -
Giovanni Giorgi -
goran.krampe＠bluefish.se -
Ned Konz