Re: On the future of WO (here we go again)
Re: On the future of WO (here we go again)
- Subject: Re: On the future of WO (here we go again)
- From: Schoenenberger Dominique <email@hidden>
- Date: Mon, 25 Mar 2019 15:53:11 +0000
- Thread-topic: On the future of WO (here we go again)
I have implemented a Single Page Application getting information from WO REST
generic services.
The Single Page Application is using also the Direct To Web rules from WO. This
idea would be to be able to have a full Javascript interface on top of your
existing business logic and D2W rules. The only problem is that you loose the
EOF transaction mechanism when saving with web services.
Anyway, if you are interested, I have a GitHub project. It is far from finished
(a lot of D2W components are missing) but you can have a look if you want:
https://github.com/domschoen/d2spa
For serving WO REST services and rules, this WO Application has to be running
also:
https://github.com/domschoen/D2SPAServer
SPA application communicate with WO app through web socket.
Dominique
On 20 Mar 2019, at 10:35, Gino Pacitti
<email@hidden<mailto:email@hidden>> wrote:
Are there any examples of the usage showing userinfo v annotations - is like to
move butcwoukd really like to see an implementation
Is there sufficient documentation on github?
Sent from my Apple iPhone 7 plus
On 20 Mar 2019, at 02:55, Faizel Dakri
<email@hidden<mailto:email@hidden>> wrote:
Hi Andrus,
Thanks for the pointers. It’s been a little while since I looked at moving to
Cayenne, so this is good information. I think I might try going the annotations
route or settle on interfaces, as Hugi suggested (I already do something like
that, however it is driven from the EOModel userInfo when generating my parent
_EOEntity classes). In any case, it is good to know that the foundations for
metadata support is there if needed.
Regards,
F
--
Faizel Dakri
email@hidden<mailto:email@hidden>
On Mar 19, 2019, at 06:54 AM, Andrus Adamchik
<email@hidden<mailto:email@hidden>> wrote:
Hi Faizel,
FWIW, Cayenne actually supports various custom metadata in the model. There is
a generic extension mechanism that allows any tool (CayenneModeler, class
generator, etc.) to embed and read stuff in the project XML that is not a part
of the main schema, that can be associated with specific model objects. Some
examples where we use it internally:
1. Cayenne 4.1 (that just went beta the other day) allows to embed "dbImport"
tool information in XML. It is used to keep your model in sync with incremental
DB changes.
2. (Perhaps more relevant) 4.1 also has a "comment" field for every object,
editable in the Modeler, that generates <info:property> tags in an alternative
namespace. E.g.:
<obj-entity name="Artist" className="org.apache.cayenne.testdo.testmap.Artist"
dbEntityName="ARTIST">
<obj-attribute name="dateOfBirth" type="java.util.Date"
db-attribute-path="DATE_OF_BIRTH">
<info:property
xmlns:info="http://cayenne.apache.org/schema/10/info<https://eur02.safelinks.protection.outlook.com/?url=http://cayenne.apache.org/schema/10/info&data=02|01|email@hidden|d22653b2f70a4216c55008d6ad177073|e573309544254f08b6ba487b9a46a425|0|0|636886713530738599&sdata=9mXJkR0lqsq0IsbsBfUh42aI0fr1ha341JA9+2WqnSI=&reserved=0>"
name="comment" value="attribute comment"/>
</obj-attribute>
<info:property
xmlns:info="http://cayenne.apache.org/schema/10/info<https://eur02.safelinks.protection.outlook.com/?url=http://cayenne.apache.org/schema/10/info&data=02|01|email@hidden|d22653b2f70a4216c55008d6ad177073|e573309544254f08b6ba487b9a46a425|0|0|636886713530748613&sdata=RGrINs0B+1EC97Aq+H200WDQRjiMw6klHRDQrLFlNy0=&reserved=0>"
name="comment" value="test comment"/>
</obj-entity>
3. Cayenne 4.2 includes class generation settings in the model.
So the mechanism to extend project metadata is there. Using it to your own ends
is still a bit challenging. The API is somewhat obscure. So my advice would be
to look at the alternative designs. But if they prove unsatisfactory, we'd
welcome a discussion about further extensions on Cayenne dev@ list. We are
almost there and if someone makes this feature a priority, there's a
straightforward road to implementing it.
Andrus
On Mar 18, 2019, at 7:50 AM, Faizel Dakri
<email@hidden<mailto:email@hidden>> wrote:
Hi Maik,
In your conversion from EOF to Cayenne, did you have any issues with metadata
embedded inside your EOModel userInfo dictionaries and if so, how you did you
go about solving them? I’ve been looking at Cayenne as a replacement for EOF
and one roadblock I am running into at the moment is support for a userInfo
type structure in the Cayenne datamap. Admittedly, it’s been about 6 months or
so since I’ve looked, but from what I could tell, this appeared to be an open
issue with Cayenne. It looked like there might be some idea on how to implement
it at one point, but I did not see any resolution or implementation of it.
I make extensive use of the EOModel userInfo dictionary (primarily on entities,
but also on properties) to identify things that are configured at runtime. For
example, I have a key named “taggable” that drives the template generation of
my _EOEntity.java files. I also use userInfo entries to specify information
for my auditing framework (e.g. being able to specify whether or an entity is
audited, which keys to audit, etc.) or my custom filtering framework (e.g. to
be able to turn on custom searches for an entity and to identify the keys that
can be used in custom searches). These are just a few examples. My current
thinking is to separate this metadata from the model and move it into its own
configuration file, but that opens up the risk of the metadata getting out of
sync with the model. It also seems a little dirty to me.
Curious if anyone else is in a similar position, or has already solved such an
issue?
Regards,
F
--
Faizel Dakri
email@hidden<mailto:email@hidden>
On Mar 15, 2019, at 10:18 AM, Maik Musall
<email@hidden<mailto:email@hidden>> wrote:
Hi Mark,
In 2017, Hugi and I converted a large project (>800.000 lines) from EOF to
Cayenne, within a few months. Had parallel branches for a while and then
switched in production, never looked back. Cayenne is similar enough that most
of the work is either boilerplate conversion or actually making use of the
newly-gained benefits. Very few hard problems encountered, and all solved.
Let's have a talk in Frankfurt about what your EOF specifics actually are.
Maik
Am 15.03.2019 um 15:34 schrieb Morris, Mark
<email@hidden<mailto:email@hidden>>:
Just to throw our 2¢ in, we have an extremely large codebase that is very
heavily invested in EOF, using it in several ways that dive deep into its
bowels. ;-) Of course, we also use the WOF part of WO, and all of Wonder.
Regards,
Mark
On Mar 15, 2019, at 5:51 AM, Hugi Thordarson
<email@hidden<mailto:email@hidden>> wrote:
Hi all.
In preparation for the coming WODay in Frankfurt, I'd love it if you'd be open
to having a discussion on the status and future of WO, so we can enter the
coming work prepared.
I'd like to begin by sharing my own thoughts on the matter, based on my current
stack and experience. It's a rehash of something I posted to our Slack
yesterday, may sound revolutionary and will no doubt be controversial, but I
think some outside-the-box thinking is required at this time. This is lengthy,
sorry about that…
--
In the past few years I've been working towards minimising the use and effect
of WO/Wonder on my stack, so when and if The Time comes, I and my customers
have a migration path forward. Among the things I've done is move from EOF to
Cayenne and from Ant to Maven (to make using 3rd party jars, including Cayenne
easier), both of which have turned out to have been very happy decisions which
I wholeheartedly recommend, regardless of anything else you do.
I love working with my WO/Cayenne stack, which is currently only "polluted" by
the following frameworks:
-- WO:
* JavaFoundation (indirectly through WO, I never use foundation classes in my
code unless absolutely required by WO)
* JavaWebObjects
-- Wonder (I consider Wonder "polluted" since it depends on WO/EOF)
* ERExtensions (only the WO stuff, not the EOF stuff)
• Ajax
• WOOgnl (indirectly for parsing Wonder-style inline templates)
…and of course then there's the deployment stuff (JavaMonitor,wotaskd,
adaptors).
Given this, here's my proposal for a way forward:
* We abandon EOF (and, in fact, any ORM—this is not meant to be a full stack
effort, initially at least)
* We re-implement JavaWebObjects as required (and the absolutely necessary
parts of JavaFoundation, such as KVC and NSBundle) as a single framework
* We separate the necessary WO stuff from the EOF/D2W stuff in Wonder (as well
as other totally unrelated things like mail sending frameworks, other utility
frameworks and "useful applications") and include it in our re-implementation
* We create a fork of WOLips that knows how to live within the New Universe
* We rule the world
Ideally, what we end with is Just a Web Framework™ with IDE integration (and
nothing else) that can serve as a basis for future development. While
re-implementing WO may sound like a huge undertaking, I actually think it's
smaller than rewriting all of my solutions that depend on it. This probably
applies to more of you.
Now, looking at my own stack I know this proposal might sound a bit
self-serving, but I'd like to hear other opinions. I believe it's a realistic
way forward with (comparatively) minimal development effort. Turns out that WOF
itself is the only part of the WO/Wonder stack that I really just don't want to
live without.
This is something I'd like to do, and if anyone likes the idea and is willing
to participate, I'm confident we can make this work! Doing stuff alone sucks.
Cheers,
- hugi
_______________________________________________
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<mailto:email@hidden>
_______________________________________________
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<mailto:email@hidden>
_______________________________________________
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<mailto:email@hidden>
_______________________________________________
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<mailto:email@hidden>
_______________________________________________
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<mailto:email@hidden>
_______________________________________________
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<mailto:email@hidden>
_______________________________________________
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:
https://eur02.safelinks.protection.outlook.com/?url=https://lists.apple.com/mailman/options/webobjects-dev/dominique.schoenenberger%40nagra.com&data=02|01|email@hidden|d22653b2f70a4216c55008d6ad177073|e573309544254f08b6ba487b9a46a425|0|0|636886713530798641&sdata=PvpjX42hoz9OjU25tbosZQ0FBoHdYlpeL6EvcpBLaMM=&reserved=0
This email sent to
email@hidden<mailto: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