Deployer Documentation

[adrian.brock]

Bill wrote.

As an aside, with those classes, it will also know that you don't want to be
invoked for deploy/undeploy if there is no such attachment.
i.e. no longer any need for the boiler place
Code:

if (unit.getAttachment(MyMetaData.class) == null)
return;



If you don't want this filtering, you can turn it off with
Code:

public MyDeployer()
{
super(MyMetaData.class);
setAllInputs(true);
}





IMO, there's just too much implicity in both the old and new deployment architecture. My experience writing the first deployer in this new architecture was that I had to dive through a lot of internal code to figure out what the hell was going on.

That's because there's never been documatation.
The old framework was only ever a prototype so we could flush out
requirements, its not surprising people did it wrong.

It seems like this is getting worse with the new refactoring you did. I honestly don't care about saving one line of if attachment exists code. It actually makes the code more readable and more importantly, more understandable for people using your deployer as an example for writing their own.

Its not about saving lines of code, its about avoid errors.
If the code won't let you do it wrong, then you can't do it wrong.

It was unbelievable how many obvious NPE problems I saw in the deployers
you and others wrote. :-(

It's also about telling the deployer framework what you want
*declaritively* so it can understand and optimize things.

I realise old "c" style coders like their "ifs" and methods that are 10 pages long :-)
but OO is a different style/mentality.
Of course documentation is required to explain how to use the framework.

Its really very simple once you grok the bigger picture.

[adrian.brock]

Ales wrote:

IMO, there's just too much implicity in both the old and new deployment architecture. My experience writing the first deployer in this new architecture was that I had to dive through a lot of internal code to figure out what the hell was going on. It seems like this is getting worse with the new refactoring you did. I honestly don't care about saving one line of if attachment exists code. It actually makes the code more readable and more importantly, more understandable for people using your deployer as an example for writing their own.


I disagree with you.
If we can have a lot of stuff pre-written, to help and 'guide' the devs, than that's what we should do. And the new Deployers do exactly that.

But then we should have a good documentation. :-)
I can start the MC RefManual with the Deployers if you guys need that asap.

[alesj]

Yup, waiting for you to start a new thread.
But I _had_ to reply to Bill and his not OO approach. :-)

On Monday I can start with Reference Manual (and a simple example addition to existing User Guide) on the Deployers, since I think the changes that we (Adrian) will make will not be that drastic for me not to be able to fit them back in.