Carey, The manual step now serves as a confirmation that the "patch" was applied correctly and makes the replacement of existing functionality explicit. That's why I don't see it as a problem at the moment. We try to automate most of our patches using our installer however, so the renaming is not something a user would do. Automatic rename/overwrite would be very bad in our scenario as a customer or consultant could have changed "standard" workflow. The renaming step makes people aware of the fact that something has changed, and that any RFCs on that piece of workflow has to be checked.
But I guess we're talking different scenario's here. If you are in a typical test->acceptance->production migration, the "auto rename" stuff could be usefull. But I think it is better solved using good tooling that allows to create a real patch. That tool would also need rollback functionality etc. In the current implementation a guide is a "container" just as a packing list or application. The uniqueness of the containers should be not only on the name, but also on the type of the container. That would fix the name clash issues with guides easy. Hugo On 8/15/07, Carey Matthew Black <[EMAIL PROTECTED]> wrote: > > Hugo, > > The benefit is that there does not need to be a manual step. If the > software can do the job, then why ask a person to do it? > > Fields/forms have internal IDs that are the root of their > function/definition. But these values are not GGUID. They are > localized to the ARS server. ( And their usefulness is limited by that > choice.) If an object is "owned" by a vendor, then the customer should > only "push it aside" and implement their own object in it's place. If > that can be done in a way that allows for the new object to be > protected from the vendors patch/installer and allows the > patch/installer to find the vendor's object, then that is what I am > after. And the less I have to do to make all of that happen the > better. > > Furthermore, why does the name actually matter to the function of the > object? > > The only places that I see names as being more useful than GGUIDs > would be to allow the customer to "replace" an OOB part with a custom > part. Form views and maybe guide names come to mind as the only "good > things" that I can think of like that. Sure you could argue that > Guides contents should be object name based and not GGUID based, but I > think you would be "working to hard" to keep the functionality correct > in that case. But having the ability to rename(enable/disable) a guide > and sub in your own (based on name) might be a very good choice for a > customization design pattern for those objects too. > > -- > Carey Matthew Black > Remedy Skilled Professional (RSP) > ARS = Action Request System(Remedy) > > Love, then teach > Solution = People + Process + Tools > Fast, Accurate, Cheap.... Pick two. > > > > > On 8/15/07, Hugo Visser <[EMAIL PROTECTED]> wrote: > > ** My bet is that AR Developer Studio will be built on Eclipse and > therefore > > it will be much easier to integrate with VCS's like CVS and SVN that > already > > have a team provider in Eclipse. I'm not sure how the copy-merge model > of > > CVS and SVN are a good fit when it comes to AR development however. > > > > I understand the guid thing now, but I don't see the benifit. If you are > > renaming stuff on the server and you are writing a patch instruction, > I'd > > rather have an explicit "rename" step as opposed to "import this and it > will > > automatically rename things" step. But maybe my view is different as my > > company is supplying patches to our customers for ExpertDesk today. > > > > Hugo > > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where > the Answers Are" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
