Re: WO Jobs in Southern Germany

2015-12-30 Thread Miguel Arroz
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.

  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).

  - 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? 
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. 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.

  - 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.

  - 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.

  Regards,

Miguel Arroz


> 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/arroz%40guiamac.com
> 
> This email sent to ar...@guiamac.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

Fwd: WO Jobs in Southern Germany

2015-12-30 Thread Jürgen Simon
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/archive%40mail-archive.com

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

Fwd: WO Jobs in Southern Germany

2015-12-30 Thread Jürgen Simon
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/archive%40mail-archive.com

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

Ajax ?

2015-12-30 Thread Calven Eggert
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&drop 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/archive%40mail-archive.com

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

ERCaptcha with Java 1.8 shows black image only

2015-12-30 Thread CHRISTOPH WICK | i4innovation GmbH, Bonn
Hi List,

has anyone running ERCaptcha with Java 1.8 successfully?

All I get is a black image when running Java 1.8 - in a project that works 
perfectly on my other machine with Java 1.7.

I found this on StackOverflow:

> This JCaptcha library is really old, and going by the state of their code 
> repository, it is an abandoned project. The problem with this library is that 
> it uses very specific version of JH Labs Image filters for CAPTCHA image 
> distortion, and this version does not support JDK 1.8, it only supports 1.6.


(s. 
http://stackoverflow.com/questions/22894510/jcaptcha4struts2-plugin-image-not-loading)
 This may be something completely different, but it’s the best hint I found so 
far.

Any hint appreciated.

C.U.CW
-- 
The three great virtues of a programmer are Laziness, Impatience and Hubris. 
(Randal Schwartz)


 ___
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