POST / Redirect / GET

[Jason Osgood]

Always redirect after POST, right?

http://en.wikipedia.org/wiki/Post/Redirect/Get

Is there ever a case you wouldn’t want to PRG?

I ask because I’m relearning web app development and in the process refining my web framework (martini).

If PRG is the norm, most of the time, I can simplify the flow of control.

Thanks.



------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/seajug/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/seajug/join
(Yahoo! ID required)

<*> To change settings via email:
seajug-digest-***@public.gmane.org
seajug-fullfeatured-***@public.gmane.org

<*> To unsubscribe from this group, send an email to:
seajug-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo Groups is subject to:
http://info.yahoo.com/legal/us/yahoo/utos/terms/

[George Smith]

In the framework that we created the last time I did a "traditional" web
site, the PRG was only applied if the form "submit" was successful, and
hence all the data could be "pulled" by ID, otherwise ALL the user's input
has to be encoded in the "get" url - which IS a NON-starter (from a
security perspective) - so that it can re-populate the form.

George

Post by Jason Osgood
Always redirect after POST, right?
http://en.wikipedia.org/wiki/Post/Redirect/Get
Is there ever a case you wouldn’t want to PRG?
I ask because I’m relearning web app development and in the process
refining my web framework (martini).
If PRG is the norm, most of the time, I can simplify the flow of control.
Thanks.
------------------------------------
Yahoo Groups Links

[Konstantin Ignatyev]

Why do you consider hairy get to be a non-starter from security perspective
George?
All those things on URL are passed encrypted over https as the (s) in http
works on transport layer.

Post by George Smith
In the framework that we created the last time I did a "traditional" web
site, the PRG was only applied if the form "submit" was successful, and
hence all the data could be "pulled" by ID, otherwise ALL the user's input
has to be encoded in the "get" url - which IS a NON-starter (from a
security perspective) - so that it can re-populate the form.
George
--

Konstantin Ignatyev

PS: If this is a typical day on planet Earth, humans will add fifteen
million tons of carbon to the atmosphere, destroy 115 square miles of
tropical rainforest, create seventy-two miles of desert, eliminate between
forty to one hundred species, erode seventy-one million tons of topsoil,
add 2,700 tons of CFCs to the stratosphere, and increase their population
by 263,000

Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs a
Strategy for Reforming Universities and Public Schools. New York: State
University of New York Press, 1997: (4) (5) (p.206)

[George Smith]

On the assumption that "hairy get" meant fully encoding ALL user input,
then there are two problem:

1. URLs (weither they be http / https) get recorded in bookmarks, copied
between browsers on your machine, and even replicated across the cloud - so
there is definitely a risk of leaking private data out (and all URL
encoding schemes I've seen have been quite weak).
2. The "spec" says that the URL will be preserved up to 4096 bytes long.
While I have seen longer work, I have also seen them truncated (when I
tried to encode too much data).


George


On Tue, Dec 17, 2013 at 9:57 PM, Konstantin Ignatyev

Post by Konstantin Ignatyev
Why do you consider hairy get to be a non-starter from security
perspective George?
All those things on URL are passed encrypted over https as the (s) in http
works on transport layer.

Post by George Smith
In the framework that we created the last time I did a "traditional" web
site, the PRG was only applied if the form "submit" was successful, and
hence all the data could be "pulled" by ID, otherwise ALL the user's input
has to be encoded in the "get" url - which IS a NON-starter (from a
security perspective) - so that it can re-populate the form.
George
--

Konstantin Ignatyev
PS: If this is a typical day on planet Earth, humans will add fifteen
million tons of carbon to the atmosphere, destroy 115 square miles of
tropical rainforest, create seventy-two miles of desert, eliminate between
forty to one hundred species, erode seventy-one million tons of topsoil,
add 2,700 tons of CFCs to the stratosphere, and increase their population
by 263,000
Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs a
Strategy for Reforming Universities and Public Schools. New York: State
University of New York Press, 1997: (4) (5) (p.206)

[Konstantin Ignatyev]

#2 - real
#1 - yes, potentially is a risk, but not greater than have 'private' data
laying on personal computer

IMO #2 plus inability to encode images/files if they are supposed to be
submitted is a killer for gets, not the security.

Post by George Smith
On the assumption that "hairy get" meant fully encoding ALL user input,
1. URLs (weither they be http / https) get recorded in bookmarks,
copied between browsers on your machine, and even replicated across the
cloud - so there is definitely a risk of leaking private data out (and all
URL encoding schemes I've seen have been quite weak).
2. The "spec" says that the URL will be preserved up to 4096 bytes
long. While I have seen longer work, I have also seen them truncated (when
I tried to encode too much data).
George

Post by Konstantin Ignatyev
Why do you consider hairy get to be a non-starter from security
perspective George?
All those things on URL are passed encrypted over https as the (s) in
http works on transport layer.

Post by George Smith
In the framework that we created the last time I did a "traditional" web
site, the PRG was only applied if the form "submit" was successful, and
hence all the data could be "pulled" by ID, otherwise ALL the user's input
has to be encoded in the "get" url - which IS a NON-starter (from a
security perspective) - so that it can re-populate the form.
George
--

Konstantin Ignatyev
PS: If this is a typical day on planet Earth, humans will add fifteen
million tons of carbon to the atmosphere, destroy 115 square miles of
tropical rainforest, create seventy-two miles of desert, eliminate between
forty to one hundred species, erode seventy-one million tons of topsoil,
add 2,700 tons of CFCs to the stratosphere, and increase their population
by 263,000
Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs
a Strategy for Reforming Universities and Public Schools. New York: State
University of New York Press, 1997: (4) (5) (p.206)

--
"And the users exclaimed with a laugh and a taunt: It's just what we
asked for but not what we want." -- Unknown

--
Konstantin Ignatyev

PS: If this is a typical day on planet Earth, humans will add fifteen
million tons of carbon to the atmosphere, destroy 115 square miles of
tropical rainforest, create seventy-two miles of desert, eliminate between
forty to one hundred species, erode seventy-one million tons of topsoil,
add 2,700 tons of CFCs to the stratosphere, and increase their population
by 263,000

Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs a
Strategy for Reforming Universities and Public Schools. New York: State
University of New York Press, 1997: (4) (5) (p.206)

[Douglas Pearson]

We fell into the trap George is talking about by accidentally leaving a GET
open on a request (which should have only accepted POSTs), which allowed us
to send information related to a user's credit card in via the GET. It was
all under HTTPS of course, but the problem was we have access logging of
all requests turned on which for a GET logs the URL and parameters. For a
POST it (reasonably enough) only logs the URL.

Much log scrubbing and backup deleting had to ensue to remove the
potentially sensitive info from our log files.

Doug

On Wed, Dec 18, 2013 at 12:24 AM, Konstantin Ignatyev

Post by Konstantin Ignatyev
#2 - real
#1 - yes, potentially is a risk, but not greater than have 'private' data
laying on personal computer
IMO #2 plus inability to encode images/files if they are supposed to be
submitted is a killer for gets, not the security.

Post by George Smith
On the assumption that "hairy get" meant fully encoding ALL user input,
1. URLs (weither they be http / https) get recorded in bookmarks,
copied between browsers on your machine, and even replicated across the
cloud - so there is definitely a risk of leaking private data out (and all
URL encoding schemes I've seen have been quite weak).
2. The "spec" says that the URL will be preserved up to 4096 bytes
long. While I have seen longer work, I have also seen them truncated (when
I tried to encode too much data).
George
On Tue, Dec 17, 2013 at 9:57 PM, Konstantin Ignatyev <

Post by Konstantin Ignatyev
Why do you consider hairy get to be a non-starter from security
perspective George?
All those things on URL are passed encrypted over https as the (s) in
http works on transport layer.

Post by George Smith
In the framework that we created the last time I did a "traditional"
web site, the PRG was only applied if the form "submit" was successful, and
hence all the data could be "pulled" by ID, otherwise ALL the user's input
has to be encoded in the "get" url - which IS a NON-starter (from a
security perspective) - so that it can re-populate the form.
George
--

Konstantin Ignatyev
PS: If this is a typical day on planet Earth, humans will add fifteen
million tons of carbon to the atmosphere, destroy 115 square miles of
tropical rainforest, create seventy-two miles of desert, eliminate between
forty to one hundred species, erode seventy-one million tons of topsoil,
add 2,700 tons of CFCs to the stratosphere, and increase their population
by 263,000
Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs
a Strategy for Reforming Universities and Public Schools. New York: State
University of New York Press, 1997: (4) (5) (p.206)

--
"And the users exclaimed with a laugh and a taunt: It's just what we
asked for but not what we want." -- Unknown

--
Konstantin Ignatyev
PS: If this is a typical day on planet Earth, humans will add fifteen
million tons of carbon to the atmosphere, destroy 115 square miles of
tropical rainforest, create seventy-two miles of desert, eliminate between
forty to one hundred species, erode seventy-one million tons of topsoil,
add 2,700 tons of CFCs to the stratosphere, and increase their population
by 263,000
Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs a
Strategy for Reforming Universities and Public Schools. New York: State
University of New York Press, 1997: (4) (5) (p.206)

[Konstantin Ignatyev]

Yeah, forgot about that internal spy!

Doug, what the hell you are doing replying at 2:40AM?! Hope that
sleeplessness is not caused by your injured back.


On Wed, Dec 18, 2013 at 2:43 AM, Douglas Pearson

Post by Douglas Pearson
We fell into the trap George is talking about by accidentally leaving a
GET open on a request (which should have only accepted POSTs), which
allowed us to send information related to a user's credit card in via the
GET. It was all under HTTPS of course, but the problem was we have access
logging of all requests turned on which for a GET logs the URL and
parameters. For a POST it (reasonably enough) only logs the URL.
Much log scrubbing and backup deleting had to ensue to remove the
potentially sensitive info from our log files.
Doug
On Wed, Dec 18, 2013 at 12:24 AM, Konstantin Ignatyev <

Post by Konstantin Ignatyev
#2 - real
#1 - yes, potentially is a risk, but not greater than have 'private' data
laying on personal computer
IMO #2 plus inability to encode images/files if they are supposed to be
submitted is a killer for gets, not the security.

Post by George Smith
On the assumption that "hairy get" meant fully encoding ALL user input,
1. URLs (weither they be http / https) get recorded in bookmarks,
copied between browsers on your machine, and even replicated across the
cloud - so there is definitely a risk of leaking private data out (and all
URL encoding schemes I've seen have been quite weak).
2. The "spec" says that the URL will be preserved up to 4096 bytes
long. While I have seen longer work, I have also seen them truncated (when
I tried to encode too much data).
George
On Tue, Dec 17, 2013 at 9:57 PM, Konstantin Ignatyev <

Post by Konstantin Ignatyev
Why do you consider hairy get to be a non-starter from security
perspective George?
All those things on URL are passed encrypted over https as the (s) in
http works on transport layer.

Post by George Smith
In the framework that we created the last time I did a "traditional"
web site, the PRG was only applied if the form "submit" was successful, and
hence all the data could be "pulled" by ID, otherwise ALL the user's input
has to be encoded in the "get" url - which IS a NON-starter (from a
security perspective) - so that it can re-populate the form.
George
--

Konstantin Ignatyev
PS: If this is a typical day on planet Earth, humans will add fifteen
million tons of carbon to the atmosphere, destroy 115 square miles of
tropical rainforest, create seventy-two miles of desert, eliminate between
forty to one hundred species, erode seventy-one million tons of topsoil,
add 2,700 tons of CFCs to the stratosphere, and increase their population
by 263,000
Bowers, C.A. The Culture of Denial: Why the Environmental Movement
State University of New York Press, 1997: (4) (5) (p.206)

--
"And the users exclaimed with a laugh and a taunt: It's just what we
asked for but not what we want." -- Unknown

--
Konstantin Ignatyev
PS: If this is a typical day on planet Earth, humans will add fifteen
million tons of carbon to the atmosphere, destroy 115 square miles of
tropical rainforest, create seventy-two miles of desert, eliminate between
forty to one hundred species, erode seventy-one million tons of topsoil,
add 2,700 tons of CFCs to the stratosphere, and increase their population
by 263,000
Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs
a Strategy for Reforming Universities and Public Schools. New York: State
University of New York Press, 1997: (4) (5) (p.206)

--
Konstantin Ignatyev

PS: If this is a typical day on planet Earth, humans will add fifteen
million tons of carbon to the atmosphere, destroy 115 square miles of
tropical rainforest, create seventy-two miles of desert, eliminate between
forty to one hundred species, erode seventy-one million tons of topsoil,
add 2,700 tons of CFCs to the stratosphere, and increase their population
by 263,000

Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs a
Strategy for Reforming Universities and Public Schools. New York: State
University of New York Press, 1997: (4) (5) (p.206)

[Eric Jain]

On Wed, Dec 18, 2013 at 5:00 PM, Konstantin Ignatyev

Doug, what the hell you are doing replying at 2:40AM?! Hope that sleeplessness is not caused by your injured back.

Could also be that he's somewhere where 2:40AM PST is a perfectly
reasonable time of the day? ;-)


------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/seajug/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/seajug/join
(Yahoo! ID required)

<*> To change settings via email:
seajug-digest-***@public.gmane.org
seajug-fullfeatured-***@public.gmane.org

<*> To unsubscribe from this group, send an email to:
seajug-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo Groups is subject to:
http://info.yahoo.com/legal/us/yahoo/utos/terms/

[Douglas Pearson]

Australia today. New Zealand tomorrow.

Sun, sand and surf - so don't feel bad for me :)

Doug

Post by Eric Jain
On Wed, Dec 18, 2013 at 5:00 PM, Konstantin Ignatyev

Post by Konstantin Ignatyev
Doug, what the hell you are doing replying at 2:40AM?! Hope that

sleeplessness is not caused by your injured back.
Could also be that he's somewhere where 2:40AM PST is a perfectly
reasonable time of the day? ;-)

[George Smith]

I agree that the security risk is low, but at at some companies I have/am
working at, it is a show stopper. In any case, I practice the motto:

It only takes ONE good bullet (point) to kill (a theory / plan).


George


On Wed, Dec 18, 2013 at 12:24 AM, Konstantin Ignatyev

Post by Konstantin Ignatyev
#2 - real
#1 - yes, potentially is a risk, but not greater than have 'private' data
laying on personal computer
IMO #2 plus inability to encode images/files if they are supposed to be
submitted is a killer for gets, not the security.

Post by George Smith
On the assumption that "hairy get" meant fully encoding ALL user input,
1. URLs (weither they be http / https) get recorded in bookmarks,
copied between browsers on your machine, and even replicated across the
cloud - so there is definitely a risk of leaking private data out (and all
URL encoding schemes I've seen have been quite weak).
2. The "spec" says that the URL will be preserved up to 4096 bytes
long. While I have seen longer work, I have also seen them truncated (when
I tried to encode too much data).
George
On Tue, Dec 17, 2013 at 9:57 PM, Konstantin Ignatyev <

Post by Konstantin Ignatyev
Why do you consider hairy get to be a non-starter from security
perspective George?
All those things on URL are passed encrypted over https as the (s) in
http works on transport layer.

Post by George Smith
In the framework that we created the last time I did a "traditional"
web site, the PRG was only applied if the form "submit" was successful, and
hence all the data could be "pulled" by ID, otherwise ALL the user's input
has to be encoded in the "get" url - which IS a NON-starter (from a
security perspective) - so that it can re-populate the form.
George
--

Konstantin Ignatyev
PS: If this is a typical day on planet Earth, humans will add fifteen
million tons of carbon to the atmosphere, destroy 115 square miles of
tropical rainforest, create seventy-two miles of desert, eliminate between
forty to one hundred species, erode seventy-one million tons of topsoil,
add 2,700 tons of CFCs to the stratosphere, and increase their population
by 263,000
Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs
a Strategy for Reforming Universities and Public Schools. New York: State
University of New York Press, 1997: (4) (5) (p.206)

--
"And the users exclaimed with a laugh and a taunt: It's just what we
asked for but not what we want." -- Unknown

--
Konstantin Ignatyev
PS: If this is a typical day on planet Earth, humans will add fifteen
million tons of carbon to the atmosphere, destroy 115 square miles of
tropical rainforest, create seventy-two miles of desert, eliminate between
forty to one hundred species, erode seventy-one million tons of topsoil,
add 2,700 tons of CFCs to the stratosphere, and increase their population
by 263,000
Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs a
Strategy for Reforming Universities and Public Schools. New York: State
University of New York Press, 1997: (4) (5) (p.206)

[Konstantin Ignatyev]

The problem is that everybody think differently about what constitutes a
'good' bullet.

Anyway, in case of data over get url, it is easily solvable by having
temp state on server so on post all the date is submitted is stored with a
unique key, and then on get can be either rendered into form fields (if
server does rendering), or returned as part of page ( js data, or in a
hidden field).

Still, in the year 2013 I would _not_ suggest doing this. It is so much
easier to work and post json data.

Post by George Smith
I agree that the security risk is low, but at at some companies I have/am
It only takes ONE good bullet (point) to kill (a theory / plan).
George
On Wed, Dec 18, 2013 at 12:24 AM, Konstantin Ignatyev <

Post by Konstantin Ignatyev
#2 - real
#1 - yes, potentially is a risk, but not greater than have 'private' data
laying on personal computer
IMO #2 plus inability to encode images/files if they are supposed to be
submitted is a killer for gets, not the security.

Post by George Smith
On the assumption that "hairy get" meant fully encoding ALL user input,
1. URLs (weither they be http / https) get recorded in bookmarks,
copied between browsers on your machine, and even replicated across the
cloud - so there is definitely a risk of leaking private data out (and all
URL encoding schemes I've seen have been quite weak).
2. The "spec" says that the URL will be preserved up to 4096 bytes
long. While I have seen longer work, I have also seen them truncated (when
I tried to encode too much data).
George
On Tue, Dec 17, 2013 at 9:57 PM, Konstantin Ignatyev <

Post by Konstantin Ignatyev
Why do you consider hairy get to be a non-starter from security
perspective George?
All those things on URL are passed encrypted over https as the (s) in
http works on transport layer.

Post by George Smith
In the framework that we created the last time I did a "traditional"
web site, the PRG was only applied if the form "submit" was successful, and
hence all the data could be "pulled" by ID, otherwise ALL the user's input
has to be encoded in the "get" url - which IS a NON-starter (from a
security perspective) - so that it can re-populate the form.
George
--

Konstantin Ignatyev
PS: If this is a typical day on planet Earth, humans will add fifteen
million tons of carbon to the atmosphere, destroy 115 square miles of
tropical rainforest, create seventy-two miles of desert, eliminate between
forty to one hundred species, erode seventy-one million tons of topsoil,
add 2,700 tons of CFCs to the stratosphere, and increase their population
by 263,000
Bowers, C.A. The Culture of Denial: Why the Environmental Movement
State University of New York Press, 1997: (4) (5) (p.206)

--
"And the users exclaimed with a laugh and a taunt: It's just what we
asked for but not what we want." -- Unknown

--
Konstantin Ignatyev
PS: If this is a typical day on planet Earth, humans will add fifteen
million tons of carbon to the atmosphere, destroy 115 square miles of
tropical rainforest, create seventy-two miles of desert, eliminate between
forty to one hundred species, erode seventy-one million tons of topsoil,
add 2,700 tons of CFCs to the stratosphere, and increase their population
by 263,000
Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs
a Strategy for Reforming Universities and Public Schools. New York: State
University of New York Press, 1997: (4) (5) (p.206)

--
"And the users exclaimed with a laugh and a taunt: It's just what we
asked for but not what we want." -- Unknown

--
Konstantin Ignatyev

PS: If this is a typical day on planet Earth, humans will add fifteen
million tons of carbon to the atmosphere, destroy 115 square miles of
tropical rainforest, create seventy-two miles of desert, eliminate between
forty to one hundred species, erode seventy-one million tons of topsoil,
add 2,700 tons of CFCs to the stratosphere, and increase their population
by 263,000

Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs a
Strategy for Reforming Universities and Public Schools. New York: State
University of New York Press, 1997: (4) (5) (p.206)

[Jason Osgood]

Great replies, discussion. Especially JSON v HTML and security. Thank you.

I now realize I should have stated “PRG for HTTP POSTs for HTML forms”.

the PRG was only applied if the form "submit" was successful … otherwise ALL the user’s
input has to be encoded in the "get" url ... so that it can re-populate the form.

Hmmm. I might’ve accidentally got that part right.

Martini auto populates a Page’s fields, forms, etc. from either a GET’s query params or a POST’s form data. Pages (code generated HTML -> Java ) work as-is out of the box. That enables an HTML-first workflow.

You get the HTML from creative (UX, web designer, script monkey), add it to your project, it works immediately in “echo back” mode. Then you the dev can progressively implement the backend at your leisure. For instance, populate drop lists from a database vs using the default data and selections found in the original HTML.


About JSON and AJAX...

However, when more modern approach is used, i.e. JSON data post then post can return new data.
Before you jump on me, please see how angularjs works http://angularjs.org/

That’s an excellent point. I’m not there yet. But this is how I anticipate handling non-HTML…

Martini treats HTML as source code. It also has partial support for prototypical HTTP requests, treating them as source as well. So the source file Details.http.request contains:

GET /course/{dept}/{number}/{term}

Right now, that parameterized query is fed into Page compiler, e.g. Page.getURI() {…} and when you register a Page (at startup), that URI is added to the route (dispatch) table.

In the near future, HTTP GET headers will be supported. For instance, cookies will be modeled and part of the code generation, matching content type will be stated upfront and used by the router, etc.

After that, prototypical HTTP responses will be supported.

These HTTP requests and responses declare their content-type. Once non-HTML content is supported, martini will have the information to route requests directly. The router will have enough information to PRG for HTML forms and “marco polo” for JSON.


I do not yet know if I’ll jump on the JSON bandwagon. I’m cool with AJAX, dynamic content, progressive rendering. But I’m leaning towards server generated HTML snippets vs JSON -> HTML generation on the client.

We’ll see.


Cheers, Jason




------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/seajug/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/seajug/join
(Yahoo! ID required)

<*> To change settings via email:
seajug-digest-***@public.gmane.org
seajug-fullfeatured-***@public.gmane.org

<*> To unsubscribe from this group, send an email to:
seajug-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo Groups is subject to:
http://info.yahoo.com/legal/us/yahoo/utos/terms/

[Konstantin Ignatyev]

Jason,

From outsiders perspective (mine) it looks like you are reimplementing

Wicket or Play

You say:
==
Martini treats HTML as source code. It also has partial support for
prototypical HTTP requests, treating them as source as well. So the source
file Details.http.request contains:

GET /course/{dept}/{number}/{term}
===

I think:
How it is different from Wicket
mountPage("/motorcycle-rental/info/${ml-id}/#{tab}",
classOf[MotoLocationInfoPage])

${ml-id} is mandatory part of URL and
#{tab} is optional


You say:
==
You get the HTML from creative (UX, web designer, script monkey), add it to
your project, it works immediately in “echo back” mode. Then you the dev
can progressively implement the backend at your leisure. For instance,
populate drop lists from a database vs using the default data and
selections found in the original HTML.
==

I think: it is _exactly_ how Wicket works


There might be reasons for you to work on Martini, but I fail to see them.
Care to explain in terms of comparison with more established frameworks
like Wicket or Play?


You say:
==
I do not yet know if I’ll jump on the JSON bandwagon. I’m cool with AJAX,
dynamic content, progressive rendering. But I’m leaning towards server
generated HTML snippets vs JSON -> HTML generation on the client.
==

I have been there, and all probably know that I am a big fan on Wicket
framework (and the likes) and statically typed languages. However, I took
the plunge and tried AngularJS for a small real project first, and now
there is no coming back. When applied judicially AngularJS made me 5x more
productive.

If there is interest I can give a talk describing how I replaced 85% of my
Wicket with Angular while making app faster and more maintainable -
Java/Scala guy perspective on using raw JavaScript sprinkled with magic
dust.

By the way AngularJS supports the workflow you mention: external HTML made
by designers added to project and then progressively enhanced.

Great replies, discussion. Especially JSON v HTML and security. Thank you.
I now realize I should have stated “PRG for HTTP POSTs for HTML forms”.

the PRG was only applied if the form "submit" was successful 
 otherwise

ALL the user’s

input has to be encoded in the "get" url ... so that it can re-populate

the form.
Hmmm. I might’ve accidentally got that part right.
Martini auto populates a Page’s fields, forms, etc. from either a GET’s
query params or a POST’s form data. Pages (code generated HTML -> Java )
work as-is out of the box. That enables an HTML-first workflow.
You get the HTML from creative (UX, web designer, script monkey), add it
to your project, it works immediately in “echo back” mode. Then you the dev
can progressively implement the backend at your leisure. For instance,
populate drop lists from a database vs using the default data and
selections found in the original HTML.
About JSON and AJAX...

However, when more modern approach is used, i.e. JSON data post then

post can return new data.

Before you jump on me, please see how angularjs works

http://angularjs.org/
That’s an excellent point. I’m not there yet. But this is how I anticipate
handling non-HTML

Martini treats HTML as source code. It also has partial support for
prototypical HTTP requests, treating them as source as well. So the source
GET /course/{dept}/{number}/{term}
Right now, that parameterized query is fed into Page compiler, e.g.
Page.getURI() {
} and when you register a Page (at startup), that URI is
added to the route (dispatch) table.
In the near future, HTTP GET headers will be supported. For instance,
cookies will be modeled and part of the code generation, matching content
type will be stated upfront and used by the router, etc.
After that, prototypical HTTP responses will be supported.
These HTTP requests and responses declare their content-type. Once
non-HTML content is supported, martini will have the information to route
requests directly. The router will have enough information to PRG for HTML
forms and “marco polo” for JSON.
I do not yet know if I’ll jump on the JSON bandwagon. I’m cool with AJAX,
dynamic content, progressive rendering. But I’m leaning towards server
generated HTML snippets vs JSON -> HTML generation on the client.
We’ll see.
Cheers, Jason
------------------------------------
Yahoo Groups Links

--
Konstantin Ignatyev

PS: If this is a typical day on planet Earth, humans will add fifteen
million tons of carbon to the atmosphere, destroy 115 square miles of
tropical rainforest, create seventy-two miles of desert, eliminate between
forty to one hundred species, erode seventy-one million tons of topsoil,
add 2,700 tons of CFCs to the stratosphere, and increase their population
by 263,000

Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs a
Strategy for Reforming Universities and Public Schools. New York: State
University of New York Press, 1997: (4) (5) (p.206)

[Jeff Ramsdale]

Thymeleaf, too, allows designers to write HTML, including fake data, and
the developer can override the content at run time. Thymeleaf templates
display in a browser (with fake data), rendered correctly, simplifying the
development cycle:

http://www.thymeleaf.org/

-jeff


On Wed, Dec 18, 2013 at 11:20 AM, Konstantin Ignatyev

Post by Konstantin Ignatyev
Jason,
From outsiders perspective (mine) it looks like you are reimplementing
Wicket or Play
==
Martini treats HTML as source code. It also has partial support for
prototypical HTTP requests, treating them as source as well. So the source
GET /course/{dept}/{number}/{term}
===
How it is different from Wicket
mountPage("/motorcycle-rental/info/${ml-id}/#{tab}",
classOf[MotoLocationInfoPage])
${ml-id} is mandatory part of URL and
#{tab} is optional
==
You get the HTML from creative (UX, web designer, script monkey), add it
to your project, it works immediately in “echo back” mode. Then you the dev
can progressively implement the backend at your leisure. For instance,
populate drop lists from a database vs using the default data and
selections found in the original HTML.
==
I think: it is _exactly_ how Wicket works
There might be reasons for you to work on Martini, but I fail to see them.
Care to explain in terms of comparison with more established frameworks
like Wicket or Play?
==
I do not yet know if I’ll jump on the JSON bandwagon. I’m cool with AJAX,
dynamic content, progressive rendering. But I’m leaning towards server
generated HTML snippets vs JSON -> HTML generation on the client.
==
I have been there, and all probably know that I am a big fan on Wicket
framework (and the likes) and statically typed languages. However, I took
the plunge and tried AngularJS for a small real project first, and now
there is no coming back. When applied judicially AngularJS made me 5x
more productive.
If there is interest I can give a talk describing how I replaced 85% of my
Wicket with Angular while making app faster and more maintainable -
Java/Scala guy perspective on using raw JavaScript sprinkled with magic
dust.
By the way AngularJS supports the workflow you mention: external HTML made
by designers added to project and then progressively enhanced.

Post by Jason Osgood
Great replies, discussion. Especially JSON v HTML and security. Thank you.
I now realize I should have stated “PRG for HTTP POSTs for HTML forms”.

the PRG was only applied if the form "submit" was successful …

otherwise ALL the user’s

input has to be encoded in the "get" url ... so that it can re-populate

the form.
Hmmm. I might’ve accidentally got that part right.
Martini auto populates a Page’s fields, forms, etc. from either a GET’s
query params or a POST’s form data. Pages (code generated HTML -> Java )
work as-is out of the box. That enables an HTML-first workflow.
You get the HTML from creative (UX, web designer, script monkey), add it
to your project, it works immediately in “echo back” mode. Then you the dev
can progressively implement the backend at your leisure. For instance,
populate drop lists from a database vs using the default data and
selections found in the original HTML.
About JSON and AJAX...

However, when more modern approach is used, i.e. JSON data post then

post can return new data.

Before you jump on me, please see how angularjs works

http://angularjs.org/
That’s an excellent point. I’m not there yet. But this is how I
anticipate handling non-HTML…
Martini treats HTML as source code. It also has partial support for
prototypical HTTP requests, treating them as source as well. So the source
GET /course/{dept}/{number}/{term}
Right now, that parameterized query is fed into Page compiler, e.g.
Page.getURI() {…} and when you register a Page (at startup), that URI is
added to the route (dispatch) table.
In the near future, HTTP GET headers will be supported. For instance,
cookies will be modeled and part of the code generation, matching content
type will be stated upfront and used by the router, etc.
After that, prototypical HTTP responses will be supported.
These HTTP requests and responses declare their content-type. Once
non-HTML content is supported, martini will have the information to route
requests directly. The router will have enough information to PRG for HTML
forms and “marco polo” for JSON.
I do not yet know if I’ll jump on the JSON bandwagon. I’m cool with AJAX,
dynamic content, progressive rendering. But I’m leaning towards server
generated HTML snippets vs JSON -> HTML generation on the client.
We’ll see.
Cheers, Jason
------------------------------------
Yahoo Groups Links

--
Konstantin Ignatyev
PS: If this is a typical day on planet Earth, humans will add fifteen
million tons of carbon to the atmosphere, destroy 115 square miles of
tropical rainforest, create seventy-two miles of desert, eliminate between
forty to one hundred species, erode seventy-one million tons of topsoil,
add 2,700 tons of CFCs to the stratosphere, and increase their population
by 263,000
Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs a
Strategy for Reforming Universities and Public Schools. New York: State
University of New York Press, 1997: (4) (5) (p.206)

[Konstantin Ignatyev]

Yes, I think we at large realized that template based approach with
progressive enhancements and instant feedback loop is the way to develop
presentation layers, so there are multiple frameworks trying to facilitate
the workflow.

But as a user or evaluator of such frameworks I would love to see them to
be presented in terms of comparison with similar ones, not just: Hey look!
there is another one doing the same.

For example: there is http://emberjs.com/ which looks _exactly_ like
angularjs so I wish emberjs has this on the very first page
http://discuss.emberjs.com/t/angularjs-vs-emberjs/1029/4 and angular had
something similar that would explain their choices.

Post by Jeff Ramsdale
Thymeleaf, too, allows designers to write HTML, including fake data, and
the developer can override the content at run time. Thymeleaf templates
display in a browser (with fake data), rendered correctly, simplifying the
http://www.thymeleaf.org/
-jeff
On Wed, Dec 18, 2013 at 11:20 AM, Konstantin Ignatyev <

Post by Konstantin Ignatyev
Jason,
From outsiders perspective (mine) it looks like you are reimplementing
Wicket or Play
==
Martini treats HTML as source code. It also has partial support for
prototypical HTTP requests, treating them as source as well. So the source
GET /course/{dept}/{number}/{term}
===
How it is different from Wicket
mountPage("/motorcycle-rental/info/${ml-id}/#{tab}",
classOf[MotoLocationInfoPage])
${ml-id} is mandatory part of URL and
#{tab} is optional
==
You get the HTML from creative (UX, web designer, script monkey), add it
to your project, it works immediately in “echo back” mode. Then you the dev
can progressively implement the backend at your leisure. For instance,
populate drop lists from a database vs using the default data and
selections found in the original HTML.
==
I think: it is _exactly_ how Wicket works
There might be reasons for you to work on Martini, but I fail to see
them. Care to explain in terms of comparison with more established
frameworks like Wicket or Play?
==
I do not yet know if I’ll jump on the JSON bandwagon. I’m cool with AJAX,
dynamic content, progressive rendering. But I’m leaning towards server
generated HTML snippets vs JSON -> HTML generation on the client.
==
I have been there, and all probably know that I am a big fan on Wicket
framework (and the likes) and statically typed languages. However, I took
the plunge and tried AngularJS for a small real project first, and now
there is no coming back. When applied judicially AngularJS made me 5x
more productive.
If there is interest I can give a talk describing how I replaced 85% of
my Wicket with Angular while making app faster and more maintainable -
Java/Scala guy perspective on using raw JavaScript sprinkled with magic
dust.
By the way AngularJS supports the workflow you mention: external HTML
made by designers added to project and then progressively enhanced.

Post by Jason Osgood
Great replies, discussion. Especially JSON v HTML and security. Thank you.
I now realize I should have stated “PRG for HTTP POSTs for HTML forms”.

the PRG was only applied if the form "submit" was successful 


otherwise ALL the user’s

input has to be encoded in the "get" url ... so that it can

re-populate the form.
Hmmm. I might’ve accidentally got that part right.
Martini auto populates a Page’s fields, forms, etc. from either a GET’s
query params or a POST’s form data. Pages (code generated HTML -> Java )
work as-is out of the box. That enables an HTML-first workflow.
You get the HTML from creative (UX, web designer, script monkey), add it
to your project, it works immediately in “echo back” mode. Then you the dev
can progressively implement the backend at your leisure. For instance,
populate drop lists from a database vs using the default data and
selections found in the original HTML.
About JSON and AJAX...

However, when more modern approach is used, i.e. JSON data post then

post can return new data.

Before you jump on me, please see how angularjs works

http://angularjs.org/
That’s an excellent point. I’m not there yet. But this is how I
anticipate handling non-HTML

Martini treats HTML as source code. It also has partial support for
prototypical HTTP requests, treating them as source as well. So the source
GET /course/{dept}/{number}/{term}
Right now, that parameterized query is fed into Page compiler, e.g.
Page.getURI() {
} and when you register a Page (at startup), that URI is
added to the route (dispatch) table.
In the near future, HTTP GET headers will be supported. For instance,
cookies will be modeled and part of the code generation, matching content
type will be stated upfront and used by the router, etc.
After that, prototypical HTTP responses will be supported.
These HTTP requests and responses declare their content-type. Once
non-HTML content is supported, martini will have the information to route
requests directly. The router will have enough information to PRG for HTML
forms and “marco polo” for JSON.
I do not yet know if I’ll jump on the JSON bandwagon. I’m cool with
AJAX, dynamic content, progressive rendering. But I’m leaning towards
server generated HTML snippets vs JSON -> HTML generation on the client.
We’ll see.
Cheers, Jason
------------------------------------
Yahoo Groups Links

--
Konstantin Ignatyev
PS: If this is a typical day on planet Earth, humans will add fifteen
million tons of carbon to the atmosphere, destroy 115 square miles of
tropical rainforest, create seventy-two miles of desert, eliminate between
forty to one hundred species, erode seventy-one million tons of topsoil,
add 2,700 tons of CFCs to the stratosphere, and increase their population
by 263,000
Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs
a Strategy for Reforming Universities and Public Schools. New York: State
University of New York Press, 1997: (4) (5) (p.206)

--
Konstantin Ignatyev

PS: If this is a typical day on planet Earth, humans will add fifteen
million tons of carbon to the atmosphere, destroy 115 square miles of
tropical rainforest, create seventy-two miles of desert, eliminate between
forty to one hundred species, erode seventy-one million tons of topsoil,
add 2,700 tons of CFCs to the stratosphere, and increase their population
by 263,000

Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs a
Strategy for Reforming Universities and Public Schools. New York: State
University of New York Press, 1997: (4) (5) (p.206)

[Jason Osgood]

Hi Jeff.

Thymeleaf, too, allows designers to write HTML, including fake data, and the developer can
override the content at run time.

Great tip. Thank you.

I was briefly excited that someone else had stumbled apon the "martini strategy".

Alas.

Thymeleaf is still a template language. Further, from my brief look at its examples, it still does runtime resolution, a la Velocity, FreeMarker, etc.

Martini is an untemplate engine. There is no code within content. There are no handle bars, mustaches, pragmas, variables, state, conditionals. Just straight HTML. Compiled to Java. [1]

Martini infers a Page's Model from the document's structure. It finds fields, lists, tables, and forms. You then mark the structural elements you care about with the "martini" attribute.

Here is a very simple login HTML page called Login.html.


<!doctype html>
<html>
<body>
<span> Status Message Here </span>
<form method="POST">
<input type="text" name="username" placeholder="Username" value="" />
<input type="password" name="password" placeholder="Password" value="" />
<input type="submit" value="Login" />
</form>
</body>
</html>

Obviously, it contains a status field, a login form containing a username and password fields.

I add martini attributes to status field and form.

<!doctype html>
<html>
<body>
<span martini="status"> Status Message Here </span>
<form martini="credentials" method="POST">
<input type="text" name="username" placeholder="Username" value="" />
<input type="password" name="password" placeholder="Password" value="" />
<input type="submit" value="Login" />
</form>
</body>
</html>

The martini compiler will emit Login.java, LoginCredentialsForm.java, and Login.aron. Looks a bit like this pseudo code (elided for brevity):

class Login extends Page
{
public Object status;
public LoginCredentialsForm credentialsForm;

public void render( HttpServletResponse response )
throws ServletException, IOException
{
...
writer.write( "<span martini=\"status\">" + status + "</span>" );
...
writer.write( "<input ... value=\" + credentialsForm.username + "\" />" );
writer.write( "<input ... value=\" + credentialsForm.password + "\" />" );
...
}
}


class LoginCredentialsForm
{
public Object username;
public Object password;
}


# ARON 0.1
import ambrose.Login
import ambrose.LoginCredentialsForm

page:Login
(
status " Status Message Here "
credentialsForm LoginCredentialsForm
(
username ""
password ""
)
)


I've omitted much. But hopefully this conveys the gist.


Now imagine Login.html is in source control and the UX person (web monkey) continues to fart around with styling, content, placement, etc. So long as UX keeps the martini attributes in place, all the downstream code will continue to compile and run. And when someone does change a martini attribute, eg change martini="credentials" to martini="bananacake", the Java compiler will catch that change (flag the new error), vs troubleshooting a broken runtime.

Some day, maybe, there’ll be a Martini IDE plugin with refactoring. So changing a field name in HTML would percolate out to your Java.


Cheers, Jason


[1] Martini is most like JSP, the current fastest template solution, if JSP were to infer your POJOs for you. If I ever migrate Martini to Netty and use NIO’s scatter/gather feature, to quickly copy arrays of character arrays, then Martini will be that much faster than JSP. In other words, Martini would be the 2nd fastest server side solution, second only to static files.




------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/seajug/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/seajug/join
(Yahoo! ID required)

<*> To change settings via email:
seajug-digest-***@public.gmane.org
seajug-fullfeatured-***@public.gmane.org

<*> To unsubscribe from this group, send an email to:
seajug-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo Groups is subject to:
http://info.yahoo.com/legal/us/yahoo/utos/terms/

[Jason Osgood]

Hi Konstantin.

Post by Konstantin Ignatyev
There might be reasons for you to work on Martini, but I fail to see them.

Because I insist that my tools work how I think. Versus getting in the way.

I was an AutoCAD guru. An early adopter, I eagerly made the jump from pen and mylar to computer. I had very little to unlearn. I happily taught others how to use AutoCAD. Over the years, I slowly realized, backed up by research, that 2D CAD tools actively thwarted the tasks of drafting and design. The Army Corps of Engineers asked “We’ve spent $500k and have not seen any improvement, any ROI. Why?"

Turns out that traditional drafting had it’s own strategies, heuristics, techniques. It’s own cognitive models. Largely implicit craft work, handed down thru verbal tradition. The CAD tools didn’t just ignore all that, they completely failed to offer a viable replacement suite of strategies, techniques, and cognitive models. AutoCAD was just a collection of weird commands for drawing 2D lines, a thin veneer over a print/plot description language. The much quoted term I coined was “chaotic mutant”.

I decided that AutoCAD is an 800lb angry stubborn gorilla sitting between me and my work.

I code for fun. When hacking on a personal project, it has to be fun. I don’t objectively know if the tools I’m creating are any better. But I do know that they don’t actively piss me off. And maybe, if I’m lucky, other people will like my tools too.

Post by Konstantin Ignatyev
Care to explain in terms of comparison with more established frameworks like Wicket or Play?

I demo’d Martini for Jon. We agreed that it’d be feasible and maybe even neat to use Martini to generate Wicket pages.

The biggest difference is the content creation workflow. Martini is HTML -> Java. Wicket is Template + Java = HTML.

The second biggest difference is Wicket has a UI-esque component model, e.g. component composition and listeners. Martini does not. I haven’t ruled out that strategy, but it’s unlikely that I’ll adopt a “live component” model.

I make CRUD apps and publishing apps. Very simple stuff.

You may recall that I’ve been trying to recreate the Access 2.0 programming model; I was never more productive. I believe I have a good start on that with fado, my SQL -> JDBC compiler.

In my work, all updates are written back to the database. No app engine, ORM, Hibernate-esque cache. When I need RDBMS caching, I’ll make a JDBC wrapper for EHCache (or some such).

For publishing apps, like showing a patient’s medical history, or a course catalog, or all the legislation, I just see that as a report writer. A web-ified Crystal Reports. Serving mostly static content. I believe martini is a good start for both CRUD web UIs and publishing reports.

FWIW, I will never willingly use Scala, Ruby, Groovy, and probably a handful of others. Life’s too short. What I did get from Play! is the courage to abandon the servlet API.

If I ever have to do a web-based rich UI, like Amazon’s AWS management console, or the work George does, I’ll look for useful tools. Relooking at AngularJS, it doesn’t appear terrible. Or maybe I'll jump off a bridge. Or, most likely, I'll make my own tools.


Cheers, Jason

------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/seajug/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/seajug/join
(Yahoo! ID required)

<*> To change settings via email:
seajug-digest-***@public.gmane.org
seajug-fullfeatured-***@public.gmane.org

<*> To unsubscribe from this group, send an email to:
seajug-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo Groups is subject to:
http://info.yahoo.com/legal/us/yahoo/utos/terms/

[Konstantin Ignatyev]

Thanks Jason

Post by Jason Osgood
Hi Konstantin.

Post by Konstantin Ignatyev
There might be reasons for you to work on Martini, but I fail to see

them.
Because I insist that my tools work how I think. Versus getting in the way.
I was an AutoCAD guru. An early adopter, I eagerly made the jump from pen
and mylar to computer. I had very little to unlearn. I happily taught
others how to use AutoCAD. Over the years, I slowly realized, backed up by
research, that 2D CAD tools actively thwarted the tasks of drafting and
design. The Army Corps of Engineers asked “We’ve spent $500k and have not
seen any improvement, any ROI. Why?"
Turns out that traditional drafting had it’s own strategies, heuristics,
techniques. It’s own cognitive models. Largely implicit craft work, handed
down thru verbal tradition. The CAD tools didn’t just ignore all that, they
completely failed to offer a viable replacement suite of strategies,
techniques, and cognitive models. AutoCAD was just a collection of weird
commands for drawing 2D lines, a thin veneer over a print/plot description
language. The much quoted term I coined was “chaotic mutant”.
I decided that AutoCAD is an 800lb angry stubborn gorilla sitting between me and my work.
I code for fun. When hacking on a personal project, it has to be fun. I
don’t objectively know if the tools I’m creating are any better. But I do
know that they don’t actively piss me off. And maybe, if I’m lucky, other
people will like my tools too.

Post by Konstantin Ignatyev
Care to explain in terms of comparison with more established frameworks

like Wicket or Play?
I demo’d Martini for Jon. We agreed that it’d be feasible and maybe even
neat to use Martini to generate Wicket pages.
The biggest difference is the content creation workflow. Martini is HTML
-> Java. Wicket is Template + Java = HTML.
The second biggest difference is Wicket has a UI-esque component model,
e.g. component composition and listeners. Martini does not. I haven’t ruled
out that strategy, but it’s unlikely that I’ll adopt a “live component”
model.
I make CRUD apps and publishing apps. Very simple stuff.
You may recall that I’ve been trying to recreate the Access 2.0
programming model; I was never more productive. I believe I have a good
start on that with fado, my SQL -> JDBC compiler.
In my work, all updates are written back to the database. No app engine,
ORM, Hibernate-esque cache. When I need RDBMS caching, I’ll make a JDBC
wrapper for EHCache (or some such).
For publishing apps, like showing a patient’s medical history, or a course
catalog, or all the legislation, I just see that as a report writer. A
web-ified Crystal Reports. Serving mostly static content. I believe martini
is a good start for both CRUD web UIs and publishing reports.
FWIW, I will never willingly use Scala, Ruby, Groovy, and probably a
handful of others. Life’s too short. What I did get from Play! is the
courage to abandon the servlet API.
If I ever have to do a web-based rich UI, like Amazon’s AWS management
console, or the work George does, I’ll look for useful tools. Relooking at
AngularJS, it doesn’t appear terrible. Or maybe I'll jump off a bridge. Or,
most likely, I'll make my own tools.
Cheers, Jason
------------------------------------
Yahoo Groups Links

--
Konstantin Ignatyev

PS: If this is a typical day on planet Earth, humans will add fifteen
million tons of carbon to the atmosphere, destroy 115 square miles of
tropical rainforest, create seventy-two miles of desert, eliminate between
forty to one hundred species, erode seventy-one million tons of topsoil,
add 2,700 tons of CFCs to the stratosphere, and increase their population
by 263,000

Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs a
Strategy for Reforming Universities and Public Schools. New York: State
University of New York Press, 1997: (4) (5) (p.206)

[Stan Dyck]

It may be a matter of opinion, but yes! POSTs should always endeavor to return a 3xx level status code.

StanD.

Post by Jason Osgood
Always redirect after POST, right?
http://en.wikipedia.org/wiki/Post/Redirect/Get
Is there ever a case you wouldn’t want to PRG?
I ask because I’m relearning web app development and in the process refining my web framework (martini).
If PRG is the norm, most of the time, I can simplify the flow of control.
Thanks.

------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/seajug/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/seajug/join
(Yahoo! ID required)

<*> To change settings via email:
seajug-digest-***@public.gmane.org
seajug-fullfeatured-***@public.gmane.org

<*> To unsubscribe from this group, send an email to:
seajug-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo Groups is subject to:
http://info.yahoo.com/legal/us/yahoo/utos/terms/

[tequilaRon]

Depends on whether you want to prevent repost via reload. Do you NEVER want to allow that? Seems a bit presumptuous if you're building a framework for others to use.  Maybe the get after post could be the norm and a special case to avoid the get could be supported? Also doesn't this only apply to applications being called by browsers outside of ajax? Who writes webapps like that any more? ;-)


Sent via the Samsung Galaxy S™III, an AT&T 4G LTE smartphone

-------- Original message --------
From: Jason Osgood <***@gmail.com>
Date: 12/17/2013 11:03 AM (GMT-08:00)
To: ***@yahoogroups.com
Subject: [seajug] POST / Redirect / GET

Always redirect after POST, right?

http://en.wikipedia.org/wiki/Post/Redirect/Get

Is there ever a case you wouldn’t want to PRG?

I ask because I’m relearning web app development and in the process refining my web framework (martini).

If PRG is the norm, most of the time, I can simplify the flow of control.

Thanks.



------------------------------------

Yahoo Groups Links

[Konstantin Ignatyev]

PRG is soo last century ;)

Seriously though, if your framework doing last century form posts then yes,
that is the way to go. However, when more modern approach is used, i.e.
JSON data post then post can return new data. Before you jump on me, please
see how angularjs works http://angularjs.org/

Post by Jason Osgood
Always redirect after POST, right?
http://en.wikipedia.org/wiki/Post/Redirect/Get
Is there ever a case you wouldn’t want to PRG?
I ask because I’m relearning web app development and in the process
refining my web framework (martini).
If PRG is the norm, most of the time, I can simplify the flow of control.
Thanks.
------------------------------------
Yahoo Groups Links

--
Konstantin Ignatyev

PS: If this is a typical day on planet Earth, humans will add fifteen
million tons of carbon to the atmosphere, destroy 115 square miles of
tropical rainforest, create seventy-two miles of desert, eliminate between
forty to one hundred species, erode seventy-one million tons of topsoil,
add 2,700 tons of CFCs to the stratosphere, and increase their population
by 263,000

Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs a
Strategy for Reforming Universities and Public Schools. New York: State
University of New York Press, 1997: (4) (5) (p.206)