Hi,
Yes, running a separate web-services layer to restrict the API
available via SOAP/XML and not vending the EOs out directly is the way
to go.
However, it is nice to have EOs that know how to serialize themselves
for different kinds of purposes so those methods are available to be
used elsewhere, or if there is any business logic in to be done during
the serialization process, that can be handled in the EO itself not in
the web services application.
Here is the scenario I am thinking about, maybe I'm missing something...
Say, a custom report showing detailed online sales for the day before.
The first array, the list of purchases can be fixed touching only the
web services layer only, modifying the POJO class to vend the
purchases as a WOStringKeyMap.
However, each Purchase object serializes itself, possibly executing
some business logic while doing it, and inside the Purchase is another
array of Products that were purchased.
Fixing this up would require modifying the business logic layer - a
wrapper method in the Purchase EO?
serializeForDetailReport() - is say the pre-existing method and is
also relied on elsewhere.
serializeForDetailReportUsingWOStringKeyMap() - would have to be made
as an additional wrapper method in the Purchase EO to implement the
workaround of not being able to vend out arrays to 5.4.1 web services
consumers.
Now if for some reason, a Product also has an array inside it, then
yet another wrapper is needed, etc.
- mike
On Feb 26, 2008, at 3:55 PM, David den Boer wrote:
A slightly better way to use webservices (especially if you expect
them to be consumed by non-WO applications) is to use primitive types.
For instance, if you need to return an array of Foo, the return type
for the service method would be Foo[].
We never expose our EO's via webservices, we usually wrap them in
POJOs which have very specific attributes for the service and non-
required attributes are not exposed.
David.
On Feb 26, 2008, at 7:22 PM, Michael DeMan wrote:
Okay,
This workaround seems to work. On the server side I put my array
elements in as keys for a WOStringKeyMap and modified the client to
get the result array back out via allKeys().
This is a huge problem however as every service, including EOs that
contain arrays, would need methods changed/wrapped to return
WOStringKeyMap instead of arrays, and this of course would have to
be done for both the server and client applications.
Does anybody know if Apple has a prioritization on getting this
fixed?
From what I can tell so far this basically makes WO5.4/5.4.1
unusable as a web services consumer (unless of course you never
need to use arrays).
- mike
On Feb 25, 2008, at 1:41 PM, Art Isbell wrote:
On Feb 25, 2008, at 9:09 AM, Michael DeMan wrote:
Does anybody know if the item noted on the posting below is fixed
in 5.4.1, and if not, could anybody describe the workaround?
http://www.mail-archive.com/[email protected]/msg15103.html
It is apparently not fixed in 5.4.1.
A workaround would be to rewrite each Web service method that
returns NSArray to return WOStringKeyMap. Each Web service client
would then need to extract the array from the WOStringKeyMap. Not
ideal, but this should work.
Aloha,
Art
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/ddenboer%40apple.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
