Tapestry and @Asset

Finished ranting about the @Script annotation, now it is time to rant about the @Asset one.

In fact, it's not about the annotation itself I wish to rant, but about the way Assets are passed. It seems to me that assets are very strictly hard-coded, if in the form of an annotation or the XML file, they're specified before-hand. However, suppose I have a dynamic page in my store, which needs to show the product's image. Since I cannot know the image's URL before-hand, I have no choice to not use the Image component. I am, in fact, forced to use the Any component, making src a dynamic attribute.

I suggest a different approach. Assets can specify hard coded items; That's a given, as it's easier for those buttons and backgrounds and whatnot. However, it should also allow Literals and OGNL which eventually translate into a String or even File objects. That way, I could do the following "classic":

img jwcid="@Image" image="ognl:item.images[0].url"

Tomcat deployment failure is popular

I guess my rant wasn't that irrelevant after all - It appears that from the Google searches which lead to my page, this is the most popular one.

Sigh... It's really a shame about that error message...

Rants about EoD and other things

I can understand people complaining about developers rushing for the newest technology (best example here). I appreciate the writer, and I agree with him in a lot of aspects. I have the same problem at my current work place, where people rush to use the latest of the languages, systems and software. Obviously, at our system, the usability of the outcome framework is irrelevant: We don't outsource our systems. However, using a language that has a big user-base and survived some time in the open market is also an advantage, having questions and relevant answers in expert forums is one major reason for that.

However, one must also need to remember the reason for these developments. And I will leave the Java vs dotNet domain for a minute and take a look at a neighbor domain: Windows vs. *nix. Anyone with a long-term memory could give a comment about how the Unix was represented during the 90s: Archaic, command-line system with a low-user base when it came to home users. Why would there be home-users anyway? It was considered a server-only system. The main reason for the shift in server-use towards the Windows systems today, in my humble opinion, is not necessarily Microsoft's promises of a better system: It's because the users grew up on a Windows system, and they feel more comfortable with it.

What Linux brought to this equations was a generation of users who grew up on a Nix system, or potentially can grow up as these systems become more comfortable for the home-user. Sure, using a Linux is not the same as using a Solaris, but the gap is not as huge as the gap from Windows 2000 to Solaris, and being familiar with these systems would give it a better voice starting from the "ground level" to the decision maker level.

Coming back to Java: Java is mature. That is why it's so difficult to add new features, especially EoD (Ease of Development) features into the language. Just to stress out the point of how difficult this is, the JSR-201 took almost 2 years to complete. On the other hand, one needs to consider the end-users: Decision makers and technical advisors are people too. If they had a nice experience with a language A and a lesser experience with language B, when they come to choose a language for their new application or their new module or about porting an application, they will take That into consideration as well, much as any statistical report or Gartner report. The human factor is important - If you grow with a certain environment you'll end up preferring it, especially if it gave you a good experience.

I know it's not required to be a rocket scientist to know any of this, but I just wanted to add my two cents about these rants.

Tapestry's Script DTD published

Could it be that my little rant helped? I am willing to swear that this wasn't here yesterday! And the site says that it was Last Published: Mon Nov 21 2005 16:50:52.

Even though I'm sure it's a total coincidence, I'm proud of myself.

Oracle, Java and data modification notifications

I've been handed a task to see if it's possible to create a single Java method which would parse old and new values in a before update/insert/delete trigger. The idea is to send the parsed data to a middle tier layer which would then propogate the data to all the business objects. We Could do that using PL/SQL, only that we'd have to create a method for every table, which is unacceptable. If, using Java, we could iterate the row's new and old columns' and retrieve the data to be parsed as XML and sent to the client, we would be happy campers.

And that's the task. The problem I've encountered so far is that no-one seems to be passing the :old or :new objects to the Java method - Only a specific value such as :old.parent_id. Is passing the :old object even possible? Is there an alternative to our solution?

I guess I leave it as an open question. I hope that soon enough I will have an answer and I could post it, as it seems interesting enough - A notification system in Oracle based on a single Java-written trigger. I'm not an Oracle DBA - I just got this task because I'm the only one with Java knowledge to be able to write a method like that (even though it seems simple enough), but it seems there isn't a really Well Defined notification mechanism for Oracle.. Am I wrong?

Tapestry 4.0 and @Script - I'm stuck!

I'm trying to create a simpe script in Tapestry. To that end, I decided to start by using their example. Too unfortunate for me, it doesn't work. Talks about root specifications when I try to run it. I am using Tapestry 4.0-beta 12, and I can only guess the example was written for Tapestry 3.0 . Or that it's not complete.

The DTD specifications page claims that A fifth type of specification, the Script specification, is described seperately. But where? The @Script page sure doesn't specify.

I'm stuck. Anyone has a clue?

Tapestry's Components

Trying to create a small component that handles user login and can be placed anywhere I stumbled into a problem where the Tapestry framework couldn't find "the components' template". Reading and re-reading the documentation assured me that I was doing it fine: A .java file in the package specified in the application specifications, a .html file in my context folder, and since it's still a requirement, a .jwc file in the WEB-INF folder.

The User's guide portion about components didn't specify where to place the templates, and the templates portion it specifies that the templates could be located either in the same location as the specification, or in the web application's context root directory.

Unfortunately, I didn't take note of the warning in paranthesis saying if the page is an application page, not a page from a component library. Why should I? My component was not coming from any library.

Just to show you, terminology in documentation is one of the most important things to prevent mistakes by the stupid users, such as myself. It seems that if the HTML templates are of a component, they need to be put with the .jwc files as well, i.e. the WEB-INF folder.

On a good side, I finally managed to get components work and I'm off the right way with remaking the store. I also wanted to note that my previous note about the store being written in ASP might have been misleading: I have not written it in ASP. I am just re-writing it in Tapestry/Cayenne, as it's highly unmaintainable at its current state.

Documentation, Documentation, Documentation!

Luckily, the great documentation of Tomcat helped me out and I found my problem.

I am pleased.

I will not share my problem in the blog; I feel to embarassed - As always, it was something stupid. As always, it was my fault.

Tomcat Deployment

So, I pulled up my sleeves and got to work. After all, if I want to switch from WebObjects to Tapestry, some configurations are in need to be done.

That's the problem, I think, with using open source applications. Sometimes the developers don't really care about the UI of their application or framework, and even though they made the best or one-of-a-kind application, users don't use it except for "hard core" people who really enjoy messing with the plumbings. I used to be like that - I think I still am - But for a seriously deployed application such as the Geekim Store I can't really fuff around writing XML files. By the way, at the moment, the site is written in ASP and is due to change to a better architectured and graphically enhanced site. This is what I actually do in my free time, even though I don't have much of it.

In spite of my last comment, I must say I was surprised to the better when I saw Cayenne's modeler and Tomcat's Manager. All that said, I still have one thing to complain about (for now): When I try to deploy my application, which is a tutorial application downloaded from the Tapestry site, I get the following message:

FAIL - Failed to deploy application at context path /taplet

Now, honestly, I can tell the context path - I chose them as input for the deployer. So what kind of information is that? "Sorry, no can do!"? How am I supposed to fix it?!

WebObjects to Cayenne

Switching to Cayenne from WebObjects was not easy, for me at least. Or maybe, it wasn't easy on the mental level, because I've already seen how easy it is to actually Do Stuff with WebObjects.

There is no doubt, however, that the switch was smooth; I'm going to count some points here about it.

1. I could use Eclipse. Or JetBrain's. Or anything. I wasn't stuck to Xcode which, as strong as it might be in the distributed builds and targeting system departments, it is still nor the Pweak in intellisense, and that's a Major minus for it in my book. It's the thing most used by code writers around the world, it's not a new technology, it shouldn't be too hard to implement (considering Apple's size to say, JetBrains'. Another advantage is the ability to use JUnit on my code to test it out.

2. Creating the model wasn't hard at all. In fact, I tried making it in three different ways, just for the heck of it: First, importing it from the database itself (as I already had a database created using WebObjects' EOModeler), second was to import the .eomodeld file, and third was to create it myself. I noticed that while the importing of EOModeler's file wasn't that accurate as it could be (for example, it didn't import the Optimistic Locking data, nor the Primary Key data), importing straight from the data source worked nicely, and creating it from scratch was as easy as creating it in EOModeler.

3. I could deploy my application Anywhere without fearing that one day it would be bound to a specific OS (Apple doesn't promise they won't do it to WebObjects, more than that: They don't guarantee it working on anything other than Mac OS X Server - Even though it can run a Single Servlet Directory on most common J2EE software-hardware combination at the moment). Just to make an emphasis: A normal J2EE container would cost around 7$/month to "rent". A WebObjects one would cost 50$/month, or buying a J2EE deployment license which, starting with WebObjects 5.3, means buying the Mac OS X Server software - 140$ I think.

4. The most important advantage here, I think, is the ability the J2SE you're used to. Not being bound to a specific NS* extension was much more relieving that I could have imaged. In WebObjects 5.3 Apple tried to make their NS* container classes implement the Collection interface, with limited success in my opinion. Another great thing is the flexibility - I think it would take Apple at least another release or two before they realise that J2SE 5 was out there and could be used. Generics are already in Cayenne, and using the EOD of J2SE 5 just makes things prettier.

There are advantages to WebObjects as well. Most of them are more in the arena of Tapestry, so I will say more on that in a different post.

So far, I'm enjoying my work with Cayenne.

PS.

I am aware that WOLips exists. I haven't tried it - So I don't know how it is. But it's only one point (even though major) out of three major points. No-one can fix the cost in money (in deployment) or in frustration (using the NS* classes).

My Java Tech Blog Is Back!

In the far past, I had a blog called "Aviad's Quest for Sentience". It was mainly about Java and my Genetic Algorithms framework I developed at the time.

This blog will also be about Java. It will be about all the projects I'll develop, both in Java or .NET, about comparisons, about genCore if I ever come to work on it again, and just about implementation ideas if I ever come to have any.

Hope I can maintain this better than I have with AQfS.