RE: WebObjects and Javascript Response Rewriter
RE: WebObjects and Javascript Response Rewriter
- Subject: RE: WebObjects and Javascript Response Rewriter
- From: GILQUIN Pierre via Webobjects-dev <email@hidden>
- Date: Sun, 5 Jan 2020 09:49:54 +0000
- Ironport-sdr: wZQl7BztWR27d31fvIk161vrEYWlXNRuYrKtdWiwEWMbfmaJNCTH0kScXcHyMAcxa5tBaSMrrL LmLQH4ECU+Ew==
- Ironport-sdr: VzCbWFBRXGzCl9L4kekzIgwo7qoCCWRr8LLKCNUkKU8H4dT/Ek8wUC6mddQhW5mA7I3Q+eBgnH t7k2PVOWIUjw==
- Thread-topic: WebObjects and Javascript Response Rewriter
Hi Aaron,
Thank you for your support and for the general review of possible framework
choices.
I will have a closer look to this alternatives possibilities.
But my current deployment environment (Hospital) is very constraint so the
server side is almost fixed with Oracle and WO/nder.
In fact, I am more on the search of an alternative of the Ajax Wonder
framework. It's ok for standard app but for an highly hierachical and dynamic
app, GWT is more adapted.
WOGWT is great for making WO and GWT worlds working together. With its
implementation of client NSArray/NSTimestamp/Key value/ etc/ classes, the
framework is abled to generate a client side tree from a root EO and its toOne
and toMany relations.
The problem is there is no support for saving an updated tree back to EO's.
So, I build my own but I am not very satisfy and it's for this matter I am
looking for better generic solution.
Thanks in advance if you have any idea …
Best, Pierre
De : Aaron Rosenzweig [mailto:email@hidden]
Envoyé : vendredi 3 janvier 2020 16:39
À : GILQUIN Pierre
Cc : email@hidden
Objet : Re: WebObjects and Javascript Response Rewriter
Hi Pierre,
Your GWT solution sounds good and useful. You made a great choice.
The beauty of traditional WO is that it was not cumbersome. You had an answer
for everything from templating UI to persisting your data and even app
monitoring / launching. You didn’t have to piece together different software
and make them work. Anything else is just going to be cumbersome. As far as I
know, nobody has made a good pure JS solution that does an
editingContext.saveChages() for a relational DB. But people like / want the
slick nice of a rich smart client living on the user’s machine. That is a fun /
slick experience for the user and it offloads a great deal of server processing
too.
Enyo is good for templating and component reuse with a visual IDE (Ares) but
then it is dead like WO and you gotta figure out persistence. They got ways to
map JS objects to rest calls but it’s cumbersome compared to traditional WO.
You got CouchDB which pretty much can avoid an app server altogether, which is
nice for simplicity… Really! You can do REST direct to a CouchDB server without
any middle tier software translation. But then CouchDB is not a relational DB
and maybe you don’t want that. That said, you can sync back and forth with
PouchDB (JS version of CouchDB) and that is easy. So maybe life can be easy if
you leave the relational world behind and pick a very particular stack.
In a mixed environment I’ve used Enyo for my pure JS app then PouchDB for its
persistence in local storage and saved the data to a large VARCHAR in a WO app.
It was a form filling app with lots of skip patterns and what not. It was cool
in that all the processing happened in the user’s browser and round trips were
only for saving the blob to WO. When the traditional WO app needed the
submitted form, it would parse the JSON structure and create EO objects and
carry on.
When I say “anything else is cumbersome” it’s not entirely true. You could fire
up something like Meteor, which has an answer for everything, and is super fast
to setup and get persistence going along with user accounts etc. The downside
is it is MongoDB only. It’s ok if you are willing to use that for persistence
but what if you want a relational DB?
WO is still perhaps the best solution for no-cumbersome relational DB usage.
Aaron Rosenzweig / Chat 'n Bike<http://www.chatnbike.com>
e: email@hidden<mailto:email@hidden> t: (301) 956-2319
[Image supprimée par l'expéditeur. Chat 'n Bike]
[Image supprimée par l'expéditeur. Chat 'n Bike]
On Jan 3, 2020, at 3:57 AM, GILQUIN Pierre via Webobjects-dev
<email@hidden<mailto:email@hidden>> wrote:
Do you have a example application with this approach?
I did a "similar" way but 100% Java using GWT and the WOGWT framework instead
of REST JSON.
The eomodel was used to generate the eo equivalent client class.
The GWT client application used RPC calls to obtain a client objects tree and
save them back on the server.
The transformation between EO server objects into client objects is rather
cumbersome. I would like to try WORest to see if it's make thing easier ...
Pierre
De : Webobjects-dev
[mailto:webobjects-dev-bounces+pierre.gilquin=email@hidden] De la
part de Aaron Rosenzweig via Webobjects-dev
Envoyé : jeudi 2 janvier 2020 20:06
À : Jesse Tayler
Cc : WO
Objet : Re: WebObjects and Javascript Response Rewriter
Sounds like you have your feet straddling two different worlds.
You could consider building parts of your app in pure JS while other parts in
WO. You could do persistence with REST for your pure JS apps that are served by
WORest. You could use JSON web tokens to have authentication that is shared
between the two worlds so that users don’t lose their authentication as they
hop back and forth.
AARON ROSENZWEIG / Chat 'n Bike
e: email@hidden<mailto:email@hidden> t: (301) 956-2319
On Jan 2, 2020, at 1:47 PM, Jesse Tayler via Webobjects-dev
<email@hidden<mailto:email@hidden>> wrote:
I see.
Well, that’s a bit of a trick but of course, you can decide what you’d like to
do.
I once realized that my UI elements often needed settings, defaults and
configurations to exist in javascript — it seemed a waste and trouble to create
new components of course, in my case, I use a lot of D2W and did not need
programming outside the regular dev tools — but I did move the css and
javascript additions into D2W rules, which made the component reliable and the
programming of details often a matter of copying configurations you know work
and writing the rule to determine when that script should be placed into the
component.
In your case, it sounds like you might want a way they can write HTML /
javascript components that are pulled from your app and then vended from the
server.
Or better yet, a stub of your page with only the HTML required to jump off a
few queries to render the rest of the page using largely website type tools
with html segments deployed somewhere.
My sense is this would not be clean and likely won’t work out the way you’d
really like it to, but who knows! Your situation might lend itself to some
design choice like these and maybe that works for you.
On Jan 2, 2020, at 1:40 PM, Jérémy DE ROYER
<email@hidden<mailto:email@hidden>> wrote:
Hi Jesse,
for the moment we are using jquery to modify the html code, but after rendering
in the client browser and our front end designers don’t feel like « real »
developpers.
I would like to give the possibility to our front-end (javascript) designers to
add their custom js code without having to change the back end that is all
written in java with webobjects
is this better explained ?
Jérémy
Le 2 janv. 2020 à 19:33, Jesse Tayler
<email@hidden<mailto:email@hidden>> a écrit :
I might be confused —
Don’t you already have control at both ends?
On Jan 2, 2020, at 1:31 PM, Jérémy DE ROYER via Webobjects-dev
<email@hidden<mailto:email@hidden>> wrote:
Hi all… and Happy New Year !
For this new year, I’de like to add a javascript postprocessor to the
webobjects response.
I mean I would like to give our front-end developpers the possiblity to rewrite
the reponse… before sending it to the customer.
Have any of you already done such a mechanism ?
Jérémy
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list
(email@hidden<mailto:email@hidden>)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden