Greetings Gentlemen, Chuck, and Davids,
I am exploring how to limit the number of columns queried and used in for a
listing in D2W. My experiment uses ERModernLook, and has a the SDSS DR1 data
set. Several of the tables have an annoyingly large number of columns (641 to
be precise) and a large
It is just hard to find in the disorganization. Start here instead:
http://www.wocommunity.org/page/default
On Dec 21, 2010, at 2:08 PM, Elim PDT wrote:
> First time using Mac OS X 10.6.5
> Trying to get WO but cannot find in Apple site
> Does apple make it public domain and stop maintain it?
First time using Mac OS X 10.6.5
Trying to get WO but cannot find in Apple site
Does apple make it public domain and stop maintain it?
___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@list
On Tue, Dec 21, 2010 at 2:07 PM, Ramsey Gurley wrote:
>
> On Dec 21, 2010, at 2:52 PM, John Huss wrote:
>
> I don't think that will work, will it? It has to call a method.
>
>
> I think you're right. Vars look like they will eat a lot of memory on
> second glance.
>
> One solution that would wor
this is why i didn't go down this path originally ... i think you can reuse
instances if you write the templates carefully (the key instance returned from
a relationship can be the same as the key instances of the destination entity),
but it just made me nervous about the amount of "stuff" it wa
On Dec 21, 2010, at 2:52 PM, John Huss wrote:
I don't think that will work, will it? It has to call a method.
I think you're right. Vars look like they will eat a lot of memory on
second glance.
One solution that would work very well would be to refactor ERXKey
and create a base clas
Thinking out loud...
It would be interesting to see how much memory the vars approach
uses... Not only does each EO get an instance, but each relationship
gets a new instance of the ERXKey subclass too... which in turn has
its own relationships and new instances. It's certainly easier to
I don't think that will work, will it? It has to call a method.
One solution that would work very well would be to refactor ERXKey and
create a base class that has a much smaller API that is non-conflicting,
then the ERXKey subclasses could use that instead.
John
On Tue, Dec 21, 2010 at 12:03 P
I wonder if we can work in atKey support...
Ramsey
On Dec 21, 2010, at 2:28 PM, Ramsey Gurley wrote:
Awesome. I like that best.
Ramsey
On Dec 21, 2010, at 1:03 PM, Timo Hoepfner wrote:
Or we use vars instead of methods:
MovieRole.pathTo.talent.photo.photo.key()
Adding a patch in a minute
Awesome. I like that best.
Ramsey
On Dec 21, 2010, at 1:03 PM, Timo Hoepfner wrote:
Or we use vars instead of methods:
MovieRole.pathTo.talent.photo.photo.key()
Adding a patch in a minute...
Timo
Am 21.12.2010 um 18:32 schrieb Timo Hoepfner:
Does this still produce the collisions that Ti
On Dec 21, 2010, at 12:32 PM, Timo Hoepfner wrote:
> I like it. Didn't know $ would be allowed within a var name. Looks like €
> would also be allowed.
Oh great. Now I have to localize my source code?!
Maybe I'll just use £ so my code is worth more. I mean really, $ could be
Canadian or Austr
Oh I like that better. :-)
By the way the patch references the "EOGenericRecord" string constant. I think
it should be ${EOGenericRecord}. Isn't that what the rest of the
_WonderEntity.java template uses.
On Dec 21, 2010, at 1:03 PM, Timo Hoepfner wrote:
> Or we use vars instead of methods
Or we use vars instead of methods:
MovieRole.pathTo.talent.photo.photo.key()
Adding a patch in a minute...
Timo
Am 21.12.2010 um 18:32 schrieb Timo Hoepfner:
Does this still produce the collisions that Timo observed? If so, I
know it isn't pretty, but I think the patch may stand a better
Does this still produce the collisions that Timo observed? If so, I
know it isn't pretty, but I think the patch may stand a better
chance if it has a prefix like
MovieRole.$path.$talent().$photo().$photo().key()
Otherwise, the next time someone wants to add a new method to
ERXKey, the chan
Il giorno 21/dic/2010, alle ore 17.34, Pascal Robert ha scritto:
>
> Le 2010-12-21 à 11:30, Giorgio Valoti a écrit :
>
>>
>> Il giorno 21/dic/2010, alle ore 14.20, Pascal Robert ha scritto:
>>
>>> Hi,
>>>
>>> You should just tell Eclipse to compile your source as 1.5-compatible so
>>> that
It tries to avoid collisions that are more likely to occur by adding "Key"
to the end of the method name, but it is still possible. I think the ideal
solution would be to have a function to detect a collection (in the template
logic) and only rename the ones that are necessary. However, even that
Le 2010-12-21 à 11:30, Giorgio Valoti a écrit :
>
> Il giorno 21/dic/2010, alle ore 14.20, Pascal Robert ha scritto:
>
>> Hi,
>>
>> You should just tell Eclipse to compile your source as 1.5-compatible so
>> that your app works with 1.6 and 1.5. Eclipse -> Preferences -> Java ->
>> Compiler
Il giorno 21/dic/2010, alle ore 14.20, Pascal Robert ha scritto:
> Hi,
>
> You should just tell Eclipse to compile your source as 1.5-compatible so that
> your app works with 1.6 and 1.5. Eclipse -> Preferences -> Java -> Compiler
> -> check Compiler compliance level to 1.5.
Hi Pascal,
I thou
On Dec 20, 2010, at 10:15 AM, John Huss wrote:
The WOLips one is the real one. You can go vote for it if you'd
like to have it.
Thanks,
John
On Mon, Dec 20, 2010 at 5:30 AM, Timo Hoepfner d...@onlinehome.de> wrote:
Already there...
http://issues.objectstyle.org/jira/browse/WONDER-617
htt
Hi,
You should just tell Eclipse to compile your source as 1.5-compatible so that
your app works with 1.6 and 1.5. Eclipse -> Preferences -> Java -> Compiler ->
check Compiler compliance level to 1.5.
> Hi,
> I’m trying to deploy an application on a Mac OS X but I have a problem with
> the jvm
Hi,
I’m trying to deploy an application on a Mac OS X but I have a problem with the
jvm version. As a regular I get the 1.6 version:
$ java -version
java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04-307-9M3263)
Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03-307, mixed
21 matches
Mail list logo
