Re: WO Jobs in Southern Germany

[Jürgen Simon]

Hello,

On 31 Dec 2015, at 02:37, Miguel Arroz  wrote:

> Hi,
> 
>> On Dec 30, 2015, at 2:46 PM, Jürgen Simon  wrote:
>> 
>> Absolutely. Proper DI facilities make things a lot easier to test. And the 
>> code much cleaner. Wouldn’t it be nice to have something like
>> 
>> @Autowired
>> EOEditingContext editingContext;
> 
>   No. Because now you have no clue where and how that editing context is 
> being created. You literally have to search the entire code base to know the 
> answer to that question. Or, let me correct myself, even then you’re not sure 
> because runtime may be different. On the other hand, if you have 
> ERXEC.newEditingContext(), you *know* what code is running to create that EC. 
> And if you have access to the code (and in Wonder, you do), you can even read 
> it, not just rely on the documentation.

I’m afraid I have to disagree. And the ability to alter the properties of the 
@Autowired object based on the environmental settings is indeed one of the 
strengths of the method. Among other things, it makes setting up testing in a 
continuous integration environment for example much easier. 

>   The reasons I hate DI frameworks like that are:
> 
>   - It makes reading (and thus understanding) the code spectacularly hard. 
> Hard to the point you may spend several hours trying to figure out what 
> object was created and injected and why that object is not the one you 
> expected to be. Keep in mind that in things like @Named the object can be 
> created anywhere in the code base. Also keep in mind that some DI frameworks, 
> like Spring, when faced with two objects in the class path for the same 
> @Named name, will silently pick one trough some arbitrary criteria, instead 
> of crashing and burning, AS THEY SHOULD DO BY DEFAULT (I know they can be 
> configured to to that, but the default behaviour is not the safe behaviour 
> which is stupid).

Not really. If you know where to look and have sufficient understanding of the 
process, it’s not a big problem in my humble opinion. Of course there is a 
learning curve, especially with Spring and that can get a little frustrating. 

>   - You have absolutely no way to know for sure what object is going to be 
> inserted unless you run the app and check it. And obviously the results of 
> doing this in your developer environment can be different from the ones in a 
> production environment. How in the world can anyone think this is a good idea?

As I mentioned above, it depends how you set things up and how well you 
understand the process. In the beginning of course I ran into these troubles, 
but once you understand how it works it’s not really that complicated. And 
again, it makes certain things a lot easier to set up. Plus it really makes for 
cleaner code (in terms of architectural concerns as well as readability). You 
won’t have to look all over the place to check if someone set the object up in 
some non standard way. If you needed specific properties on an object set, you 
can control that with DI just as well and it’s all in once place.

> You can argue that anything in Java has the same behaviour, what class you 
> get depends on the class path you have on the runtime.

I wouldn’t try to bend the argument that far. 

> However, this is a side effect of how Java was designed, and one that causes 
> much headache and is one of the major complains about the Java platform 
> (class path issues). DI is like this *by design*. It incorporates in its 
> design something that is widely recognized as a major problem of the platform.

It also enabled us to control the class loading process which in some instances 
has been the only way to fix certain problems. It is used quite extensively in 
Wonder, if not mistaken. If not for this form of ‘DI’ (although I wouldn’t call 
it that), a lot of things would have been impossible to do. 

>   - I think that if you have to mess up your code to the point of not being 
> able to know (mathematically speaking) how it works unless you run it in 
> order to make your code testable, you’re doing it wrong. If you need 
> indirections to give you different objects when running and testing, then 
> make those explicit in the code, and add them only on the places where you 
> really need it.

Well, I can understand the resistance but frankly can’t second most of the 
arguments. 

>   - It’s one more thing to deal with, configure, work around the limitations 
> and bugs, etc. And the very last thing software development needs is more of 
> that.  Overall, it seems like an extremely inelegant and complex solution to 
> the testing problem. That problem is not easy to solve, it’s true, but I 
> think overall DI brings more pain than gain.

I disagree and I think DI would be a great addition to the WO framework. 
Especially when coupled with the D2W rule engine. Also with ERXProperties. If I 
had the time I’d prototype it and add it to Wonder. Strictly optional, of 
course 

Re: Strange error using Wonder (same code works fine in WebObjects 5.3)

[Samuel Pelletier]

HI,

For the load ordering problem, if you have some wonder source projects in your 
workspace, the load order is sometime modified when launching with Eclipse. 
This does not cause problem on the server though.

I do not remember the exact cases I experienced but I burned myself in the past 
with this.

Samuel


> Le 2015-12-29 à 15:15, jazzsalsa  a écrit :
> 
> It's solved :)
> 
> I removed the ERAttributeExtension framework, but I have still no idea
> how to move make it load first. Anyway, I am on the move again.
> 
> Thanks!
> 
> Bart
> 
> On Tue, 2015-12-29 at 17:53 +0100, Fabian Peters wrote:
>> You could check the java.class.path contents that get logged on
>> application start. If ERAttributeExtension is listed before
>> JavaEOAccess there as well, then I'm at a loss.
>> 
>>> Am 29.12.2015 um 17:33 schrieb jazzsalsa :
>>> 
>>> Hi Fabian,
>>> 
>>> Thanks for the fast reply! That is already the case. it looks like
>>> this:
>>> 
>>> 
>>> 
>>> Is there anything else strange here?
>>> 
>>> Thanks in advance for your help.
>>> 
>>> Best regards, Bart
>>> 
>>> On Tue, 2015-12-29 at 16:48 +0100, Fabian Peters wrote:
 Hi Bart,
 
 The ERAttributeExtension framework has to be loaded before
 JavaEOAccess. You can change the order in your project properties
 (right-click on the project folder in eclipse):
 
 
 
 cheers, Fabian
 
> Am 29.12.2015 um 16:34 schrieb jazzsalsa :
> 
> Hi list,
> 
> I am stuck using Wonder (again, the learning curve is steep ;).
> Trying to fetch data from a postgresql database. The data looks
> like this:
> 
> creationDate (timestamptz)
> description varchar(255)
> id
> tagID
> title varchar(50)
> url varchar(50)
> 2015-12-29 13:46:19 +0100 This is a new description
> added from EOF
> 1
> 4
> New title
> http://example.com
> 
> 
> 
> 
> Fetching the data does not work as soon as I add the field
> creationDate in the database. The same database and data works
> well with an App written in WebObjects 5.3. It is a simple
> component to display the data using a repetion. Similar code is
> use in the Wonder App and the WebObjects app.
> 
> Using Wonder 6.0:
> 
> Dec 29 16:05:02 book1[39244] ERROR
> er.extensions.appserver.ERXApplication  - Exception caught:
> java.lang.NoSuchMethodError:
> com.webobjects.eoaccess.EOAttribute.newValueForDate(Ljava/lang/
> Object;)Ljava/lang/Object;
>   "CurrentPage" = "your.app.components.Main";
>   "Bundles" = {
>   "ERExtensions" = "6.2-SNAPSHOT";
>   "JavaWebObjects" = "5.4.3";
>   "WOOgnl" = "6.0";
>   "ERJars" = "6.0";
>   "PostgresqlPlugIn" = "7.0";
>   "JavaJDBCAdaptor" = "5.4.3";
>   "JavaXML" = "5.4.2";
>   "JavaEOAccess" = "5.4.3";
>   "JavaEOControl" = "5.4.2";
>   "JavaFoundation" = "5.4.3";
>   "ERAttributeExtension" = "6.0";
>   "book1" = "";
>   "JavaWOExtensions" = "6.0";
>   "ERPrototypes" = "6.0";
>   };
>   "URL" = "/cgi-bin/WebObjects/book1.woa";
> }
> 
> The attributes for the creationDate are:
> 
> {
> attributes = (
> {
> columnName = creationdate; 
> externalType = timestamptz; 
> name = creationDate; 
> prototypeName = dateTime; 
> serverTimeZone = "Europe/Amsterdam"; 
> }, 
> 
> 
> Is there something obviously wrong here?
> How can I debug this problem? (log4j.logger.er=DEBUG is already
> used) 
> 
> Thanks in advance, Bart
> 
> 
> 
> 
> 
> 
> 
> Dec 29 16:05:01 book1[39244] DEBUG NSLog  -  connecting with
> dictionary: {plugin = "Postgresql"; username = "username";
> driver = "org.postgresql.Driver"; password = " for log>"; URL = "jdbc:postgresql://intranet/bookmark"; }
> Dec 29 16:05:01 book1[39244] DEBUG NSLog  - fetching JDBC Info
> with ERXJDBCAdaptor$Context@1408135793
> Dec 29 16:05:01 book1[39244] DEBUG NSLog  -  connecting with
> dictionary: {plugin = "Postgresql"; username = "username";
> driver = "org.postgresql.Driver"; password = " for log>"; URL = "jdbc:postgresql://intranet/bookmark"; }
> Dec 29 16:05:02 book1[39244] DEBUG NSLog  - connection
> disconnected.
> Dec 29 16:05:02 book1[39244] DEBUG NSLog  -  === Begin Internal
> Transaction
> Dec 29 16:05:02 book1[39244] DEBUG
> NSLog  -  evaluateExpression:
>  t0.creationdate, t0.description, t0.id, t0.tagID, t0.title,
> t0.url, t0.url_icon FROM public.bookmark t0" withBindings: >
> Dec 29 16:05:02 book1[39244] DEBUG NSLog  - fetch canceled
> Dec 29 16:05:02 book1[39244] DEBUG 

Re: Ajax ?

[Samuel Pelletier]

Hi Calven,

I think the ghosting binding of AjaxDraggable does exactly that. 

Regards,

Samuel

> Le 2015-12-30 à 15:05, Calven Eggert  a écrit :
> 
> Happy holidays all!
> 
> I'm looking to create an Ajax page that has two lists of items.  The first 
> list, Activity 1, Activity 2, Activity 3, etc.  The second list, called 
> Steps, will be created by the user by dragging the activity items into the 
> Steps list.  The user should be able to drag the same activity from the list 
> many times.
> 
> In the Ajax drag example, when the item is dragged there is a gap in the 
> original list.  I don't want the gap to ever appear.  Is there a way to drag 
> the activity, however, not allow it to be actually be moved from the first 
> list? First cloning the item and then dropping it in the new list? 
> 
> Calven
> 
> 
> ___
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/webobjects-dev/samuel%40samkar.com
> 
> This email sent to sam...@samkar.com

 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: WO Jobs in Southern Germany

[Samuel Pelletier]

Hello,

You does not seem aware that there is 2 GitHub projects by Henrique Prange for 
Unit testing of EOF and Injection in WO. There tools have some limits but as a 
user of wounit I can testify it works.

I do not personally use woinject because I do not see the need for my projects 
(at least right now)

http://hprange.github.io/wounit/
http://hprange.github.io/woinject/

As the logic is supposed to by in the EOs, if EOs can be tested, I'm happy. I 
do not see why components should be tested. I only write tests in my Logic 
frameworks.

Regards,

Samuel


> Le 2015-12-30 à 17:46, Jürgen Simon  a écrit :
> 
> Hello,
> 
> On 28 Dec 2015, at 20:26, Andrus Adamchik  > wrote:
> 
>>  
>> On Mon, Dec 28, 2015, at 05:28 PM, Miguel Arroz wrote:
>>>   Just because those frameworks don’t explicitly have abominations like 
>>> dependency injection mechanisms, it doesn’t mean they don’t follow the IoC 
>>> principles.
>>  
>> Heh, there are DI frameworks out there that may be called abominations, but 
>> DI itself simply facilitates a very clean pluggable architecture if you use 
>> it right. And no, WO/EOF doesn't have it. And yes, it is a problem. Just ask 
>> the folks who are trying to write unit tests against EOF ;)
> 
> Absolutely. Proper DI facilities make things a lot easier to test. And the 
> code much cleaner. Wouldn’t it be nice to have something like
> 
> @Autowired
> EOEditingContext editingContext;
> 
> instead of 
> 
> EOEditingContext editingContext = ERXEC.newEditingContext()
> 
> perhaps even with some rule based setup, aka: D2W meets DI? 
> 
> Just thinking out loud.
> 
> J.
> 
> ___
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/webobjects-dev/samuel%40samkar.com
> 
> This email sent to sam...@samkar.com

 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com