In the spirit of discussion:
On Oct 23, 3:37 am, Peter Laird <
peterjla...@gmail.com> wrote:
> Hi SOFEArs,
>
> I saw Peter Svensson's Thin Server talk at AjaxWorld, and it matches
> where me and my team has been headed the last year. We are taking a
> balanced approach (mixing some server side presentation rendering with
> some Ajax+REST pieces) with great success.
>
> I read the SOFEA v1.0 document, and wrote up my comments. Hopefully
> they are helpful:
>
> Page 8 WS-* and REST are both valid service interfaces
>
> - Both SOAP and REST are considered valid service approaches according
> to the document.
> - But REST does not mandate XML to be returned! As we all know some
> REST APIs only support JSON.
> - I find the strict opposition against JSON to be strange given these
> facts since that position is based on the idea that the service
> interface will be talking XML. Not always true!
Absolutely, JSON is becoming the default communication mechanism for
web applications.
> Page 12 Thin vs. Rich
>
> - There is a blended approach as well. A sentence or two to recognize
> that will make this more objection proof.
> - Ex. A portal server handles rendering page layout, Ajax+REST
> portlets handle their own flows
> - Ex. Type ahead search boxes on standard server gen'd pages
Why would you have the portal server handling the page layout? One of
the big strengths of TSA is that for mashups/portals you just have to
put out an HTML file. Having the server rendering the page structure
breaks this.
I believe Dojo can help break up a project like this in the build
process. You would only load what you need. But, with a project that
big, I agree that splitting it up might be the best / easiest thing to
do.
> 2. Different teams of devs likely work on each section, so it helps
> componentize UI dev
I don't understand how this would make a difference. With the
application we are working on right now, we use real simple history to
break the application up into pages anyway. It is just as easy for
someone in Trucks to work along someone in Children on the client. If
you put that on the server, it gets worse because you are stepping on
the Business/Data layer developers toes.
> 3. Each section is really a related sub application, but a customer
> may want to access multiple sections, and thus share basic profile
> state across them.
Does this imply this can't be done with SOFEA?
> 4. There are business rules that may affect the inter-section
> navigation for a customer. Controller logic is needed.
> Better off with blended server side controller to manage main
> naviagation, and SOFEA for each section
Can you give an example? Typically those navigation rules are there
to protect the data from having an incorrect state. As long as your
services prevent this no matter what, why not put this logic client
side?
The great thing about replacing web 1.0 wizard style interfaces with a
TSA application (and a tool like Real Simple History) is that you can
recreate the wizard style interface, never leave your application in a
partially completed state, and still support the back button and
changing information.
However, I am not sure if this type of navigation applies. Can you
give a more concrete example?
> Page 21 Server Push
>
> - Both SOFEA and Thin-Client apps have the same limitations wrt push.
> Therefore this page doesn't seem to be relevent to the discussion?
> - Also, there workarounds as you note that exist today, and the
> standard WebSockets coming in HTML5 makes this page not so compelling.
> - Vote to strike this entire page.
>
> Page 22 Client side state
>
> - Cookies are another way to maintain state on the client
>
> Page 23: Wasting time building 50 Java controller frameworks
>
> - To be fair, we have also wasted time building at least 50 RIA
> frameworks
We've built a lot of RIA libraries. Frameworks I am not so sure
about.