GX Product management is looking for your input!

Hi there

I am currently looking into additional ways to make GX WebManager easier to install, deploy, upgrade and develop with.

So my general question is: what should we, GX, spend our precious development time on if we want to further optimize our ease of development and shorten the length of your projects?

My question has a technical angle, but if you know functional improvements that save days in your projects than please mention them as well

Much Appreciated!

Martin (GX Product Manager)

Martin,

3 things come to mind:

1. I guess API additions would be the main thing for me. The API is complete if I'm able to create a complete website through the API. That would then also mean the GX Webmanager itself could completely rely on that same API.

2. Introduce language switch within the mediarepository besides the recently introduced versions.

3. Deployable Filters

Regards,

Michel

Deployable filters/tags would indeed be very welcome.

And up to date documentation that is search-able online, so you can search it more easily on keyword (or fix it by make developerweb easier to search through).

More logging in the system is very welcome too. This makes it easier to debug if something doesn't work as expected.

The installation of the community manager seems fine to me as it is right now - I personally install a version using the .exe installer, start it up, log in and change my password, then turn it off again and create an archive (yay for winrar) of it for backup purposes. Works like a charm, no problems there.

I would however like to see it being made possible to install a number of different WebManager versions next to each other. Or wait, I think it already is, but I have one version which has some custom configuration where the path to webmanager is set directly.

But one thing that would help out in this is to have the Maven repository moved outside of the WebManager installation directory. That way, WebManager JAR-files can be placed next to each other in a single repo (as long as their version numbers are different), and you can build a 9.6 project even if you've got the 9.10 version installed... if that makes sense. Currently, I just manually copy the maven2-repository from my local 9.6 and 9.9 repositories to the currently active 9.10 installation repo, which works fine for building WCB's.

But it'd be nice if this repository was made to be separate from the webmanager installation directory. An online repository with GX libraries would be nice too I guess, but somehow I don't see that happen anytime soon (and there's not a real need for it, I think).

As for shortening the length of development, could you come over here and fix my software? . That, or convince the people around here that it is convenient to have a local development environment, instead of being forced to use the test server (with disabled logging, so you have to connect 'em manually in the system utilities window).

For setting up a project, I had created a set of new Maven archetypes that allows you to add components to an existing WCB project, even if it was developed already - only developer action that had to be taken was to add an entry to the activator (which was reduced to a single line in my development library) and to copy the language resources into a single file (because I couldn't figure out how to simply append to the existing language files).

This equated to spewing out a number of 'mvn archetype:generate' commands to get a dozen-module project set up initially. Which could all be combined into a single command, if required. That seriously reduces project setup time, because you'd no longer need to create a new project for each module you wanted to add and/or copy-paste the bits of file you wanted to transfer over.

It'll require a bit of an update to the default project setup, but I'm pretty sure it can be done without too much of a hassle.


Finally, some things I'd like to see done: Updated / expanded documentation (of all kinds), and (in the software itself), better logging / reporting of errors. It doesn't look nice when an editor gets a message saying 'Uncaught exception occurred in unknown controller'. And I don't like it whenever I see a 'java.lang.NullPointerException'-message appear in the logs without a stacktrace attached to it.

I'm pretty sure that's a matter of replacing all calls to

} catch (SomeException e)
log.severe(e.getMessage())
}

to

log.log(Level.SEVERE, e.getMessage(), e);

(Note that I too used to do the former a lot, :/)


Hum. While I'm at it...

* During development, sometimes the WCB's I update seem to not update anymore internally - I remove a log message somewhere, re-install, but the log message remains. Time for a re-install, in that case.

* It seems WebManager has troubles whenever JCR elements change - adding or removing a field often gives problems. Is there something that needs to be done when the data is altered?

* Rant.

Going off-topic for a bit to respond to what Cthulhu wrote:

As for shortening the length of development, could you come over here and fix my software? . That, or convince the people around here that it is convenient to have a local development environment, instead of being forced to use the test server (with disabled logging, so you have to connect 'em manually in the system utilities window).

Shouldn't be that hard to convince your people? Just lay down your demands!

- Always develop local! It's quick, it's controlled, it's easy to set up and it's easy to debug (even to the point where you connect Tomcat to Eclipse and step through handler or service code). Sure, there may be some things that cannot be simulated locally (missing database or service), but it does not outweigh the increase in speed and ease of development.

- Always have servers with logging enabled and accessible to you, the developer! Logs are your only way to keep tabs on the system's health. I have yet to see valid reasons why logging should be disabled on any server.

Greetings,

Patrick

Oh, an back on topic... Freak wish:

Find some way to have ctrl-space work for API functions in Eclipse.

pagecontext.website.homepage. Ehr... ctrl-space!

Is probably never going to work since jsp is not strongly typed.
Still... whoa!

Greetings,

Patrick

Responding to Ctulhu (and back off topic )

* During development, sometimes the WCB's I update seem to not update anymore internally - I remove a log message somewhere, re-install, but the log message remains. Time for a re-install, in that case.

This might be due to the behaviour of the OSGI-framework. If a dependency exists on a service, the old version of that service is left active, until a refresh. (It was a bit puzzling to me at first too...)

When developing locally, you can use the Apache Felix Shell TUI to manage this behaviour. Very useful! (Another argument to convince your colleagues...)

"An online repository with GX libraries would be nice too I guess, but somehow I don't see that happen anytime soon (and there's not a real need for it, I think)."

Thinking ahead: It would be very nice to have something like a combination of WCMExchange (http, upload), SVN-viewer (like we know them from sourceforge.net, for public wcb's) and public Maven-repo for WCB's (copy them from the upload).

This way you wouldn't need to search for your dependencies, nor save them locally. As the maven repo remembers all version uploaded ever via wcmexchange.

@Patrick: Google helps `content assistant +eclipse +"expression language"`

http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclipse.jst.jsf.... Screenshot 3. Whoha?!

I wonder how to configure it, but it doesn't seem to be impossible.

Martin,

One that things almost every trainee who is new to GX WebManager is struggling with is the naming of the following items:

- Page section ('blocks' in every example)
- Page sections ('blocks')
- Page parts

I'm not sure why the name 'Page section' was made up, but it conflicts a bit with 'Page parts'. Blocks was better in this aspect, at least for the developer.

Next: `Page section container` or 'Page section area' would probably be better than using only plurals to differentiate. This makes it clear it's a container presentation that in 99% of the cases just has a loop over some items.

(With thanks JeroenVD for pointing this one out ;))

Shouldn't be that hard to convince your people? Just lay down your demands!

- Always develop local! It's quick, it's controlled, it's easy to set up and it's easy to debug (even to the point where you connect Tomcat to Eclipse and step through handler or service code). Sure, there may be some things that cannot be simulated locally (missing database or service), but it does not outweigh the increase in speed and ease of development.

The problem is with the database, really. We need it to develop locally, but the Management indicates that the Database (notice the capital D) is Sacred, and the Unclean Should Not Touch It, Like Ever. It's worth a lot of money, company security, etc. (Disregarding the fact that I've got super administrator access and can destroy Everything with just 3 clicks, xD)

- Always have servers with logging enabled and accessible to you, the developer! Logs are your only way to keep tabs on the system's health. I have yet to see valid reasons why logging should be disabled on any server.

Speaking of, I was just granted access to the logs by the friendly people at our hoster. They're just a bit slow with such things, .

@Jorisb: Sounds good, I'll give that a try if I ever encounter the problem again (read: if I ever get to developing again, xD)

But one thing that would help out in this is to have the Maven repository moved outside of the WebManager installation directory. That way, WebManager JAR-files can be placed next to each other in a single repo (as long as their version numbers are different), and you can build a 9.6 project even if you've got the 9.10 version installed... if that makes sense. Currently, I just manually copy the maven2-repository from my local 9.6 and 9.9 repositories to the currently active 9.10 installation repo, which works fine for building WCB's.

That's already possible! When I download the latest WebManager SDK, I copy over the maven2-repository directory to my D:\, such that in D:\maven2-repository is a merged repository consisting of all WebManager releases. As long as the parent version in the pom.xml of my WCB points to a version that is in my repository, it works...

Gr,
Mark