Best-practices/ architectural patters for business apps

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Best-practices/ architectural patters for business apps

Stefan Krecher
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
Reply | Threaded
Open this post in threaded view
|

Re: Best-practices/ architectural patters for business apps

Philippe Marschall
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
Reply | Threaded
Open this post in threaded view
|

Making generated links more understandable

Larry Kellogg
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
Reply | Threaded
Open this post in threaded view
|

Re: Making generated links more understandable

Philippe Marschall
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
Reply | Threaded
Open this post in threaded view
|

Re: Making generated links more understandable

Lukas Renggli
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
Reply | Threaded
Open this post in threaded view
|

Re: Making generated links more understandable

Larry Kellogg
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
Reply | Threaded
Open this post in threaded view
|

Re: Making generated links more understandable

Larry Kellogg

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
Reply | Threaded
Open this post in threaded view
|

Re: Making generated links more understandable

Nick

 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…


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
Reply | Threaded
Open this post in threaded view
|

Re: Making generated links more understandable

Philippe Marschall
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
Reply | Threaded
Open this post in threaded view
|

Re: Making generated links more understandable

Larry Kellogg
In reply to this post by Nick

On Mar 27, 2012, at 10:15 AM, Nick Ager wrote:


 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…


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.


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




Cheers

Nick
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: Making generated links more understandable

Larry Kellogg
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
Reply | Threaded
Open this post in threaded view
|

Re: Making generated links more understandable

Nick
In reply to this post by Larry Kellogg
  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

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
Reply | Threaded
Open this post in threaded view
|

Re: Making generated links more understandable

Larry Kellogg

On Mar 27, 2012, at 11:00 AM, Nick Ager wrote:

  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

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.


  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. 

Have a look with the developer tools (firebug etc) to see what the request path is


  Thanks...

  Larry

Cheers

Nick
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: Making generated links more understandable

Nick
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:

On Mar 27, 2012, at 11:00 AM, Nick Ager wrote:

  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

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.


  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. 

Have a look with the developer tools (firebug etc) to see what the request path is


  Thanks...

  Larry

Cheers

Nick
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: Making generated links more understandable

Larry Kellogg

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:

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


  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




Cheers

Nick 



On 27 March 2012 16:10, Lawrence Kellogg <[hidden email]> wrote:

On Mar 27, 2012, at 11:00 AM, Nick Ager wrote:

  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

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.


  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. 

Have a look with the developer tools (firebug etc) to see what the request path is


  Thanks...

  Larry

Cheers

Nick
_______________________________________________
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


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Making generated links more understandable

Paul DeBruicker
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
Reply | Threaded
Open this post in threaded view
|

Re: Making generated links more understandable

Larry Kellogg

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