On Dec 6, 2007, at 11:38 AM, Galen Rhodes wrote:
Essentially what you're going to do is trap the "onSubmit" message
of the form or the "onClick" message of one of the buttons. Then
what you have to do is open a blank window and then make sure the
target for the form is the same as the ne
On Dec 7, 2007, at 1:56 PM, Jeffrey Simpson wrote:
Thanks for the prompt reply. I forgot to mention we have our own
batch
fetching that does a objectByPrimary key with a delegate that does
not do a
database fetch to weed out the object in memory.
Not too sure what you are doing there or
Thanks for the prompt reply. I forgot to mention we have our own batch
fetching that does a objectByPrimary key with a delegate that does not do a
database fetch to weed out the object in memory.
I discovered that by having the ecs use strong references it did what I
wanted. I also found out tha
Pierre,
I think this is one of the clearest explanations of the
EOEditingContext I've seen. That used to trip me up a lot when first
learning WO. I used the session's defaulting editing context for all
kinds of stuff. I just thought that was the right way by reading the
documentation on E
It is important to see the EOEditingContext as a sandbox. It's the EC
that contains your unsaved changes. It's not the "EOF stack" that is
clogged with pending updates. Other clients of the EOF stack will not
even see your local changes until they are committed.
When saving fails over a val
On Dec 7, 2007, at 8:51 AM, Chuck Hill wrote:
On Dec 6, 2007, at 11:50 PM, Art Isbell wrote:
A to-one relationship from one foreign key to a primary key
Typo: should read "from a primary key to a primary key"
must always have exactly one row in the destination entity—if this
isn’t guaran
On Dec 7, 2007, at 11:20 AM, Mike Schrag wrote:
Why stop there? Why not just shell out a 'sudo reboot now' and be
_really_ sure.
I think someone stole Chuck's lunch money this morning ...
And woke me up early to do it!
--
Practical WebObjects - for developers who want to increase their
You'd have to track down the docs that were written about it before
there's any chance of it working. I was contemplating removing it
but was afraid somewhere in the universe someone knows how to use it
and would get very upset.
https://svn.objectstyle.org/repos/woproject/tags/wolips_1_0_0_
Why stop there? Why not just shell out a 'sudo reboot now' and be
_really_ sure.
I think someone stole Chuck's lunch money this morning ...
ms
___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobj
Thanks Mike, for the hints. Now I have recreate the project starting
with a new project. Now also the builded war works in WO5.4
(obviously the javaxml.jar issue stays). But I can't revert to the
default build mode (no ssd/war) without manually edit the build.xml.
You really just need to stea
On Dec 6, 2007, at 11:50 PM, Art Isbell wrote:
On Dec 6, 2007, at 8:18 PM, Owen McKerrow wrote:
I have the following relationship :
GROUP <-- --> RQF_GROUP
where a group may have a RQF Group object, but the RQF Group
object must belong to a group.
As its a to one I want it to propagate
Thanks Mike, for the hints. Now I have recreate the project starting
with a new project. Now also the builded war works in WO5.4 (obviously
the javaxml.jar issue stays). But I can't revert to the default build
mode (no ssd/war) without manually edit the build.xml.
I think that the TargetBui
On Dec 7, 2007, at 7:01 AM, Jeffrey Simpson wrote:
I want to preload some EOs and so they are cached. I have set
ERXEC.setDefaultFetchTimestampLag(8640);
That only applies to faulting, not fetching. You might want to look
at the much feared EOSharedEditingContext or at Wonder's EO cac
On Dec 7, 2007, at 7:48 AM, Greg Lappen wrote:
Hi all,
I just recently ran into an issue where my application tried to
save a new object to the database, the save failed, and every
subsequent save failed with the same error. It seems that
WebObjects maintains a queue of updates/saves to
On 7 Dec 2007, at 16:03, Alan Ward wrote:
The unsaved objects(s) are still in your EOEditingContext and thus
any future attempts to save
will try to save them again (along with any subsequent changes).
The approach that you describe
below is not the best one. What you want to do is to ca
Hi,
Did anyone file a bug for this? If not, please do so.
I will now, as I have to rework over 100 WOComponents.
atze
Am 20.11.2007 um 19:25 schrieb Tobias Crawley:
Sam:
I believe this is a known bug in 5.4. Currently, the only fix is to
remove the package from the definition:
The option for Servlet Deployment ONLY works if you are using the most
recent build.xml files (i.e. it will not work on your older
projects). There's an obnoxious dance that happens between your
build.xml and WOLips UI for certain build controls. I'm assuming
you're using an older build.x
previously in order to build ssd/war I edited build.xml uncommenting
the ssd/war comments.
Now I have tryed to select in WOLips Build properties window the Ant
radio buttom as Build Style, and Servlet Deployment and autogenerate
web.xml checkbox, then right-click on build-xml under Package
The unsaved objects(s) are still in your EOEditingContext and thus
any future attempts to save
will try to save them again (along with any subsequent changes). The
approach that you describe
below is not the best one. What you want to do is to catch the
exception from ec.saveChanges()
and
Hi all,
I just recently ran into an issue where my application tried to save
a new object to the database, the save failed, and every subsequent
save failed with the same error. It seems that WebObjects maintains
a queue of updates/saves to write to the database, and when one
fails, it e
I want to preload some EOs and so they are cached. I have set
ERXEC.setDefaultFetchTimestampLag(8640); I preload my EOs and do some
batch fetching. Later on I use a fetch spec to query from the database some
of the cached EOs. They are fully fetched which I understand is the case.
When I then
I don't know about 5.4 ... I haven't done any testing with it for this
(there is nothing WOLips can do about javaxml.jar in 5.4 -- until that
is broken out into separate jars, it will not work in a servlet
deployment). In 5.3, a fairly simple WO app will be about 27M. SSDD
requires that y
Hi!
http://lists.macosforge.org/pipermail/webkit-dev/2007-October/
002572.html
Imagine there's no gecko
It's easy if you try
No Opera to poke around
And no IE to make you cry
Imagine all the people
Browsing on WebKit...
Yours
Miguel Arroz
Miguel Arroz
http://www.terminalapp.
for me SSDD deploy in tomcat, builded with eclipse 3.3.2, latest
WOLips, WO 5.4, leopard, produces a very huge SSDD folder (about 122
MB) with the already talked problem with javaxml.jar - jar not loaded.
It works if the application don't use any xml processing.
War deploy produces a WAR (a
24 matches
Mail list logo
