Hi,
After trying with HV2 I decided that it didn't fit my needs (it needs work, quite a bit of work), so I'm currently experimenting with Seaside for SqP. However, there's one little question I have as I have never created an app like this: how to structure the application?
Clearly, the front page is a sort of, well, front page component. All the links on it are links that I'd like to be in accordance with REST principles, so that when users visit them they get something in their location bar that's bookmarkable (the ability to have 'friendly' links was what lead me to try HV2 first).
At the moment I have a front page component that directly renders all the contents, with exception for the article entries which are rendered by embedding article view components. Say that the application url is /seaside/sqp/front, then I'd like the article 'Read more' links to point to something /seaside/sqp/article/<number>, and similarly for the account links, diary entries, etcetera. However, I fear that a) I'll have to do dirty URL hacking for this, and b) that this will force a new session, lots of applications to be maintained in /seaside/config, etcetera.
What's the cleanest way to structure this? Use Session>>addToPath: and parse URL's somewhere?
Seems that I'm having a bit of trouble with multiple components, so example code would be most welcome :-)
Regards,
Cees
To partially help in answering my own question: about 5 seconds after I pressed 'send', I remembered that SBlogLite does more-or-less the same ;-). So there seems to be a lot of knowledge to harvest there, the only question from me at the moment is: is, by whatever standard, SBlogLite deemed 'good Seaside design'?
Hi again!
Cees de Groot cg@cdegroot.com wrote:
To partially help in answering my own question: about 5 seconds after I pressed 'send', I remembered that SBlogLite does more-or-less the same ;-). So there seems to be a lot of knowledge to harvest there, the only question from me at the moment is: is, by whatever standard, SBlogLite deemed 'good Seaside design'?
I hope not - when I looked at it (just a quick look though) the URL dispatch seemed very "handcrafted" for the particular job at hand.
But I know Avi threw that code together, so no shadow on him for that of course. :)
regards, Göran
On Wed, 2003-12-17 at 09:09, goran.krampe@bluefish.se wrote:
I hope not - when I looked at it (just a quick look though) the URL dispatch seemed very "handcrafted" for the particular job at hand.
That is what you are going to have under Seaside if you want to have 'permanent' URL's - it was designed with a single entry point in mind, that was a major reason I looked at HV2 first (and of course to learn a bit about it).
But I know Avi threw that code together, so no shadow on him for that of course. :)
I know it was done in a hurry. I'm interested to know whether people like the end result (modulo probably the url dispatch method, but I'm more interested in the structuring of components)
Well, to be honest, I haven't had time to look at the SBlogLite code yet. And I do know Avi was playing with some new ideas and hacked them in. But I think he was happy with the direction and was planning on using some of the lessons learned to improve the URL dispatch stuff in Seaside.
The development branch of seaside has been refactored to greatly simplify the path a request takes coming into the system and the process for handling a URL that doesn't represent an existing session (such as a bookmarked URL).
Not that this helps you much since it's still on the -dev branch. I got the branch running at work with little trouble, though Andrew has since told me he had some weirdness with it, so it's not quite ready for prime time.
BUT, I am basically on holidays now, so I am more than happy to pull up the SBlogLite code and have a look at it, or to have a look at your stuff, Cees - I certainly have a pretty good idea what is considered "Good Seaside Design". I'm off to bed now but if you want to send me anything to look at or chat on email or IRC or something tomorrow, let me know.
Julian
Cees de Groot wrote:
On Wed, 2003-12-17 at 09:09, goran.krampe@bluefish.se wrote:
I hope not - when I looked at it (just a quick look though) the URL dispatch seemed very "handcrafted" for the particular job at hand.
That is what you are going to have under Seaside if you want to have 'permanent' URL's - it was designed with a single entry point in mind, that was a major reason I looked at HV2 first (and of course to learn a bit about it).
But I know Avi threw that code together, so no shadow on him for that of course. :)
I know it was done in a hurry. I'm interested to know whether people like the end result (modulo probably the url dispatch method, but I'm more interested in the structuring of components)
Seaside mailing list Seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/seaside
On Wed, 2003-12-17 at 09:58, Julian Fitzell wrote:
BUT, I am basically on holidays now, so I am more than happy to pull up the SBlogLite code and have a look at it, or to have a look at your stuff, Cees - I certainly have a pretty good idea what is considered "Good Seaside Design". I'm off to bed now but if you want to send me anything to look at or chat on email or IRC or something tomorrow, let me know.
The major issue is the overall 'componentizing'. If you look at SqP (easy when you're duplicating a running website ;-)), you have a top that is relatively static (I'm planning to keep it a fixed element in the new site), then two columns with various components: an article overview, some text boxes, and two lists (most recent diary entries and most recent accounts).
The major question at the moment is how to do the flow control (it's the hardest bit about Seaside, I think mostly because there's so much to unlearn). I can see there's an outer frame (with the top navbar), which holds some configuration of subcomponents. The problem I'm having is that some of the links have non-local effects - if you click on a diary entry, everything below the navbar gets replaced with one single new component. I'm mostly wondering how you can/should do that without too much coupling between the components...
On Dec 17, 2003, at 2:20 AM, Cees de Groot wrote:
On Wed, 2003-12-17 at 09:58, Julian Fitzell wrote:
BUT, I am basically on holidays now, so I am more than happy to pull up the SBlogLite code and have a look at it, or to have a look at your stuff, Cees - I certainly have a pretty good idea what is considered "Good Seaside Design". I'm off to bed now but if you want to send me anything to look at or chat on email or IRC or something tomorrow, let me know.
The major issue is the overall 'componentizing'. If you look at SqP (easy when you're duplicating a running website ;-)), you have a top that is relatively static (I'm planning to keep it a fixed element in the new site), then two columns with various components: an article overview, some text boxes, and two lists (most recent diary entries and most recent accounts).
The major question at the moment is how to do the flow control (it's the hardest bit about Seaside, I think mostly because there's so much to unlearn). I can see there's an outer frame (with the top navbar), which holds some configuration of subcomponents. The problem I'm having is that some of the links have non-local effects - if you click on a diary entry, everything below the navbar gets replaced with one single new component. I'm mostly wondering how you can/should do that without too much coupling between the components...
Ah yes, fun, fun, fun :-)
The way I usually structure mine is by having a ControlCenter or MainApp (or insert some name here) component that handles the arrangement of subcomponents. For example, a Navbar would be instantiated by this ControlCenter, as would components for the main content and the Sidebars.
When a component is created, I pass in the ControlCenter. In your above Diary example, I assume you are doing something like: Diary call: OtherComponent, but the Diary component is the only one currently active, so the call: replaces everything on the page. If you use an "ubrella" like component whose renderContentOn: just lays our your style sheet framework and uses ivars to track components corresponding the functional areas of the page, then you can replace just the one bit of functionality in the page by using the call: answer: semantics.
If you want to replace the whole page, then from any component you can do ControlCenter call: (OtherComponent new). You can successively use call: as many times as you want, and as each component sends answer: then the delegate chain unwinds.
So what I'm (not very well, I'm sure) trying to say is that the key is breaking up the page into components controlled by an "Umbrella" and figuring out which components to send call: to for the desired results.
Also, on the Navbar, judicious use of clearDelegate can return your app to it's beginning state.
And if everything I've said here is obvious to you, just ignore me ;)
Brian
Seaside mailing list Seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/seaside
Brian Brown wrote: [...]
Also, on the Navbar, judicious use of clearDelegate can return your app to it's beginning state.
Yes, though beware the use of #clearDelegate if you are using filters (including #isolate: calls which use filters) as they don't get removed properly when you do this. This is something that should be fixed in the next major seaside release as Avi is reworking the way filters work.
Julian
On Wed, 2003-12-17 at 09:58, Julian Fitzell wrote:
I'm off to bed now but if you want to send me anything to look at or chat on email or IRC or something tomorrow, let me know.
You'd do me a great favour if you could download the latest SqP code (see my SqP diary for details) and comment on the design - I think I have a workable overall structure, but as it is still young and malleable, early comments are quite welcome...
Regards,
Cees
Cees de Groot wrote:
On Wed, 2003-12-17 at 09:58, Julian Fitzell wrote:
I'm off to bed now but if you want to send me anything to look at or chat on email or IRC or something tomorrow, let me know.
You'd do me a great favour if you could download the latest SqP code (see my SqP diary for details) and comment on the design - I think I have a workable overall structure, but as it is still young and malleable, early comments are quite welcome...
Looks pretty reasonable. Your overall structure seems pretty much right on. I made a few fixes and a few changes to bring it a little more in line with how I would factor it. You're welcome to use or not use whatever parts of it you see fit. They're in beta4's MC repos at http://beta4.com/mc/sqp.
I tried to make small commits with decent comments so it each should be easily understandable I think. But shout if anything is unclear.
Take or leave what you will.
General notes:
- the profile.xml files are invalid - I had to add a / before the closing > in all the <auth> tags - calling "self session" instead of "SqpSeaSession currentSession" is preferred. It's possible that the context hack may not always be used to look that up. As long as you are calling #session on the component, we'll find some way to make that work in whatever the current scheme is. - #standardSeaLinkOn: seems problematic, mostly because it depends on #currentSession above. I think it would be better to pass in the session, or a block, or something. Or, my preference would be... eh, I'll just refactor it how I'd do it an commit the version. :) Might just be a difference of opinion <shrug> - I wonder whether the sidebars should be in components? Might not be necessary - but I think I'd like them to stay around even when you drill down deeper..?
On IRC at the moment - off to bed soonish.
Cheers,
Julian
On Thu, 2003-12-18 at 09:35, Julian Fitzell wrote:
Looks pretty reasonable. Your overall structure seems pretty much right on. I made a few fixes and a few changes to bring it a little more in line with how I would factor it. You're welcome to use or not use whatever parts of it you see fit. They're in beta4's MC repos at http://beta4.com/mc/sqp.
Thanks! I'll look at them right away.
- the profile.xml files are invalid - I had to add a / before the
closing > in all the <auth> tags
Ah - my password munger probable.
- calling "self session" instead of "SqpSeaSession currentSession" is
preferred.
Yup - I noted that myself yesterday.
- #standardSeaLinkOn: seems problematic, mostly because it depends on
#currentSession above. I think it would be better to pass in the session, or a block, or something. Or, my preference would be... eh, I'll just refactor it how I'd do it an commit the version. :) Might just be a difference of opinion <shrug>
If you're declaring #currentSession private, that's ok and a refactoring is fine.
- I wonder whether the sidebars should be in components? Might not be
necessary - but I think I'd like them to stay around even when you drill down deeper..?
Yeah, I thought about that myself. But that's all details, currently I'm mostly concerned about overal structure - I have a lot of ideas on how the final portal will look, but I'm trying very hard to resist the temptation to start tweaking right now ;-).
Ok, seems I grokked, more or less, how to structure a Seaside app. That's good - thanks for taking the trouble to read my code (it's not as bad as Vogon poetry, but only barely so).
Off to your MC version ;-)
Regards,
Cees
Hi!
Cees de Groot cg@theinternetone.net wrote:
Hi,
After trying with HV2 I decided that it didn't fit my needs (it needs work, quite a bit of work), so I'm currently experimenting with Seaside for SqP.
Bah! You infidel! :)
No worries. But just as you know, I have begun the merge of the four classes in Seaside "Base-documents" with HV2. It looks promising already.
Anyway, if you go with Seaside then you could at least grab the HVUrlStream. Sure, it is trivial to write - but nevertheless.
regards, Göran
PS. Writing a diary entry on the above first "contact" with Seaside. And damn it Seasiders - you are lousy at commenting the code! Only half joking here.
goran.krampe@bluefish.se wrote:
Hi!
Cees de Groot cg@theinternetone.net wrote:
Hi,
After trying with HV2 I decided that it didn't fit my needs (it needs work, quite a bit of work), so I'm currently experimenting with Seaside for SqP.
Bah! You infidel! :)
No worries. But just as you know, I have begun the merge of the four classes in Seaside "Base-documents" with HV2. It looks promising already.
Anyway, if you go with Seaside then you could at least grab the HVUrlStream. Sure, it is trivial to write - but nevertheless.
regards, Göran
PS. Writing a diary entry on the above first "contact" with Seaside. And damn it Seasiders - you are lousy at commenting the code! Only half joking here.
Erm... yess... well... umm... Eh, no excuse really. :)
There are parts of it that are pretty self-documenting, but there are others that don't do so well. Some of the method names don't even make sense to me :)
It needs to happen, but my work on Seaside at the moment is mostly limited to what I can justify counting as work time - and documenting an external library for others' use... though actually, when I eventually move on and they have to replace me, they'll be happier if it's documented... hmm... :)
Julian
Julian Fitzell wrote:
goran.krampe@bluefish.se wrote:
PS. Writing a diary entry on the above first "contact" with Seaside. And damn it Seasiders - you are lousy at commenting the code! Only half joking here.
Erm... yess... well... umm... Eh, no excuse really. :)
There are parts of it that are pretty self-documenting, but there are others that don't do so well. Some of the method names don't even make sense to me :)
It needs to happen, but my work on Seaside at the moment is mostly limited to what I can justify counting as work time - and documenting an external library for others' use... though actually, when I eventually move on and they have to replace me, they'll be happier if it's documented... hmm... :)
Oh, I meant to add of course that in the meantime, feel free to ask questions here :)
Julian
seaside@lists.squeakfoundation.org
-
Brian Brown -
Cees de Groot -
Cees de Groot -
goran.krampe＠bluefish.se -
Julian Fitzell