Best-practices/ architectural patters for business apps
Locked
Best-practices/ architectural patters for business apps
 
|
Hi,
i'd like to know if there are some best-practices/ patterns for seaside application architectures. I've been working in JEE Projects in the last approx 10 years - and there we've got a lot architectural best-practices. Is there some kind of MVC-Framework like Spring etc in the Java-World? How are Transactions handled? Do we have ejb-like components like stateless or stateful session beans? Or should this not be a seaside-specific question? regards, Stefan _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Best-practices/ architectural patters for business apps
|
|
Am 23. März 2012 12:49 schrieb Stefan Krecher <[hidden email]>:
> Hi, > i'd like to know if there are some best-practices/ patterns for > seaside application architectures. > I've been working in JEE Projects in the last approx 10 years - and > there we've got a lot architectural best-practices. > Is there some kind of MVC-Framework like Spring etc in the Java-World? Like Spring IoC or Spring WebMWC? Seaside-REST is similar to JAX-RS or Spring WebMWC without views. I'm not aware of anything like Spring IoC. > How are Transactions handled? Not at all / specific to the persistence backend you're using. There's nothing like @Transactional / @TransactionAttribute. > Do we have ejb-like components like stateless or stateful session beans? Nope. > Or should this not be a seaside-specific question? Seaside compares closed to something like Wicket or Tapestry (without the injection) and maybe JSF. There are parts of it that map pretty closely to JAX-RS / servlets / servlet filters but that's about it. It doesn't contain any (non-GUI) component framework, persistence framework, IoC container. Cheers Philippe _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Making generated links more understandable
|
|
Hello,
I am running Google analytics on my site and the page information is useless because it just shows the generated links which do not bear any relationship to the components being called. I thought I read about some way to name all of the pages but I can't seem to find that information. Is it possible for me to name all of my pages so that I can see where users are going on my site? Thanks, Larry _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Making generated links more understandable
|
|
Am 26. März 2012 17:33 schrieb Lawrence Kellogg <[hidden email]>:
> Hello, > I am running Google analytics on my site and the page information is > useless because it just shows the generated links which do not bear any > relationship to the components being called. I thought I read about some way > to name all of the pages but I can't seem to find that information. Is it > possible for me to name all of my pages so that I can see where users are > going on my site? You can implement #updateUrl: in your components. Cheers Philippe _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Making generated links more understandable
|
|
In reply to this post by Larry Kellogg
Hi Larry,
See this FAQ entry: http://www.seaside.st/documentation/faq/how-to#229642197. Then you can use #updateUrl: and #addToPath: to generate path segments that are picked up by GA (http://book.seaside.st/book/in-action/session/recovering). For pure AJAX applications a slight different approach is needed. That is, everything is done programmatically. Have a look at TextLint-Seaside (http://www.squeaksource.com/textlint) for an example. Lukas On 26 March 2012 17:33, Lawrence Kellogg <[hidden email]> wrote: > Hello, > I am running Google analytics on my site and the page information is > useless because it just shows the generated links which do not bear any > relationship to the components being called. I thought I read about some way > to name all of the pages but I can't seem to find that information. Is it > possible for me to name all of my pages so that I can see where users are > going on my site? > > Thanks, > > Larry > www.practicemusic.com > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Making generated links more understandable
|
|
Thanks Lukas and Phillipe.
It looks like this: updateUrl: aUrl super updateUrl: aUrl. aUrl addToPath: self class name will give me what I want. What do you think? Any drawbacks to doing this? Larry On Mar 26, 2012, at 11:41 AM, Lukas Renggli wrote: > Hi Larry, > > See this FAQ entry: http://www.seaside.st/documentation/faq/how-to#229642197. > > Then you can use #updateUrl: and #addToPath: to generate path segments > that are picked up by GA > (http://book.seaside.st/book/in-action/session/recovering). > > For pure AJAX applications a slight different approach is needed. That > is, everything is done programmatically. Have a look at > TextLint-Seaside (http://www.squeaksource.com/textlint) for an > example. > > Lukas > > On 26 March 2012 17:33, Lawrence Kellogg <[hidden email]> wrote: >> Hello, >> I am running Google analytics on my site and the page information is >> useless because it just shows the generated links which do not bear any >> relationship to the components being called. I thought I read about some way >> to name all of the pages but I can't seem to find that information. Is it >> possible for me to name all of my pages so that I can see where users are >> going on my site? >> >> Thanks, >> >> Larry >> www.practicemusic.com >> >> _______________________________________________ >> seaside mailing list >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > _______________________________________________ > 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 |
Re: Making generated links more understandable
|
|
On Mar 26, 2012, at 1:06 PM, Lawrence Kellogg wrote: > Thanks Lukas and Phillipe. > > It looks like this: > > updateUrl: aUrl > super updateUrl: aUrl. > aUrl addToPath: self class name > > will give me what I want. What do you think? Any drawbacks to doing this? I'll respond to my own question. ;-) Well, the above change works ok in my local environment with Pharo, but when I apply this change to my GLASS instance, all of my CSS and images do not get served. Does this change somehow effect how Seaside with an nginx front-end finds resources in the /var/www/glass directory? I'm not sure what is going on… Regards, Larry > > Larry > > > On Mar 26, 2012, at 11:41 AM, Lukas Renggli wrote: > >> Hi Larry, >> >> See this FAQ entry: http://www.seaside.st/documentation/faq/how-to#229642197. >> >> Then you can use #updateUrl: and #addToPath: to generate path segments >> that are picked up by GA >> (http://book.seaside.st/book/in-action/session/recovering). >> >> For pure AJAX applications a slight different approach is needed. That >> is, everything is done programmatically. Have a look at >> TextLint-Seaside (http://www.squeaksource.com/textlint) for an >> example. >> >> Lukas >> >> On 26 March 2012 17:33, Lawrence Kellogg <[hidden email]> wrote: >>> Hello, >>> I am running Google analytics on my site and the page information is >>> useless because it just shows the generated links which do not bear any >>> relationship to the components being called. I thought I read about some way >>> to name all of the pages but I can't seem to find that information. Is it >>> possible for me to name all of my pages so that I can see where users are >>> going on my site? >>> >>> Thanks, >>> >>> Larry >>> www.practicemusic.com >>> >>> _______________________________________________ >>> seaside mailing list >>> [hidden email] >>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >>> >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> _______________________________________________ >> 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 _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
Hi Larry, I'm struggling to understand what the problem is here. How are you accessing your resources? Are you using relative paths? Other than inspecting the html created looking at the resource paths to understand why Nginx isn't serving them I'm afraid I don't have an idea.
Cheers Nick _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Making generated links more understandable
|
|
In reply to this post by Larry Kellogg
Am 26. März 2012 19:06 schrieb Lawrence Kellogg <[hidden email]>:
> Thanks Lukas and Phillipe. > > It looks like this: > > updateUrl: aUrl > super updateUrl: aUrl. > aUrl addToPath: self class name > > will give me what I want. What do you think? You probably don't want to do this for every component. You may want to exclude components that appear multiple times on a page and "insignificant" ones (like footer or side bar). > Any drawbacks to doing this? If you're on GemStone IIRC class names are Symbols and not Strings like in Pharo (or was it the other way around?). And symbols are not subtypes of strings, at least not on every platform. So you might want to do: aUrl addToPath: self class name greaseString Cheers Philippe _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Making generated links more understandable
|
|
In reply to this post by Nick
On Mar 27, 2012, at 10:15 AM, Nick Ager wrote:
Hello Nick, I am also struggling to understand why everything breaks. My nginx.conf file redirects to /var/www/glass for files that I refer to in my code, so I only put 'picture.jpg' for an image, for instance, or 'bootstrap.css', and it all works great. Would you call that a relative path? If I put in that single addToPath line in updateUrl: updateUrl: aUrl super updateUrl: aUrl. aUrl addToPath: self class name nothing is found. I'm puzzled….. Larry
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Making generated links more understandable
|
|
In reply to this post by Philippe Marschall
On Mar 27, 2012, at 10:19 AM, Philippe Marschall wrote: > Am 26. März 2012 19:06 schrieb Lawrence Kellogg <[hidden email]>: >> Thanks Lukas and Phillipe. >> >> It looks like this: >> >> updateUrl: aUrl >> super updateUrl: aUrl. >> aUrl addToPath: self class name >> >> will give me what I want. What do you think? > > You probably don't want to do this for every component. You may want > to exclude components that appear multiple times on a page and > "insignificant" ones (like footer or side bar). > Yes, I realize that, thanks for pointing it out, Philippe. Unfortunately, putting in the addToPath call in even a single component messes up all of my rendering for that component, as I explained in another post. I need to fix that problem first…. >> Any drawbacks to doing this? > > If you're on GemStone IIRC class names are Symbols and not Strings > like in Pharo (or was it the other way around?). And symbols are not > subtypes of strings, at least not on every platform. So you might want > to do: > > aUrl addToPath: self class name greaseString Yes, good point. I had an asString in there at one point. I'm not clear on what a greaseString is but I guess I should find out. Regards, Larry > > Cheers > Philippe > _______________________________________________ > 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 Larry Kellogg
So in your render methods do you have code that looks like:
html image url: 'picture.jpg'. If so the request url will be relative to page path, which you are modifying by adding the class name. I'd normally develop using a file library or external file library which would look like:
html image url: MyFileLibrary / #pictureJpg. this generates html as: <img src='/files/MyFileLibrary/picture.jpg'> which is always absolute from the root.
Have a look with the developer tools (firebug etc) to see what the request path is Cheers Nick _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Making generated links more understandable
|
|
On Mar 27, 2012, at 11:00 AM, Nick Ager wrote:
Yes, I have html image tags as you describe. I have been told not to use the FileLibrary class for things like CSS, etc, because it gets cached somewhere where it shouldn't, but I am forgetting the exact reason now. So, I don't use the FileLibrary for anything, in deployment, and I'm talking about my deployed system here. This code works correctly in my local system that uses a FileLibrary.
Thanks... Larry
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Sorry I wasn't clear. I don't recommend using the file libraries for deployment, you can use them during development then write the files contained within the file library out prior to deployment using:
MYFileLibrary default deployFiles. These files can then be placed in a directory known to your font-end server such as Nginx and served by it. Of course their are plenty of other ways to develop such as using WAExternalFileLibrary found here: http://www.squeaksource.com/Seaside30LGPL, or simply placing your files on an external file server such as Amazon S3
Cheers Nick On 27 March 2012 16:10, Lawrence Kellogg <[hidden email]> wrote:
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Making generated links more understandable
|
|
On Mar 27, 2012, at 11:28 AM, Nick Ager wrote: Sorry I wasn't clear. I don't recommend using the file libraries for deployment, you can use them during development then write the files contained within the file library out prior to deployment using: Ok, but I guess the question still remains why the addToPath: command messes up serving from my nginx directory, and is there any way around it. Is there some other way I can tag the url for Google analytics without adding a path component? Larry
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Making generated links more understandable
|
|
On 12-03-27 09:09 AM, Lawrence Kellogg wrote:
>> > > Ok, but I guess the question still remains why the addToPath: command > messes up serving from my nginx directory, and is there any way around > it. Is there some other way I can tag the url for Google analytics > without adding a path component? > Are you specifying #resourceBaseUrl in your application's initialization (as recommended in the book) and specifying your images/css relative to that path as described here: http://book.seaside.st/book/in-action/serving-files/images _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Making generated links more understandable
|
|
On Mar 27, 2012, at 12:38 PM, Paul DeBruicker wrote: > On 12-03-27 09:09 AM, Lawrence Kellogg wrote: >>> >> >> Ok, but I guess the question still remains why the addToPath: command >> messes up serving from my nginx directory, and is there any way around >> it. Is there some other way I can tag the url for Google analytics >> without adding a path component? >> > > > > > Are you specifying #resourceBaseUrl in your application's initialization (as recommended in the book) and specifying your images/css relative to that path as described here: > > http://book.seaside.st/book/in-action/serving-files/images > Funny, my /config screen only shows Server Path unspecified and does not show a Resource Base URL. Why is that? Should I just set it programmatically? Larry > _______________________________________________ > 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 |
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |