On Wednesday 07 of March 2012 13:43:53 Duncan Mac-Vicar P. wrote: > I have been working on NewChannelHelper, CreateChannelCommand, > ChannelSoftwareHandler and EditChannelAction. > > Right now NewChannelHelper does some verifying and implements cloning, > while new channel creation is implemented in CreateChannelCommand. > > Basic validation is in two places, > > CreateChannelCommand validates and throws (translated) exceptions. > > NewChannelHelper implements the logic (but only answers true or false) > and then the clone operation in the same class creates an untranslated > InvalidChannelParameter exception. > > This makes sense, as NewChannelHelper::clone is used in > ChannelSoftwareHandler (xmlrpc) for the clonning, so an untranslated > error is ok (despite the duplication). > > When I refactored the validation in one place, I kept the ones from > CreateChannelCommand, which are translated. I remember Tomas Lestach > mentioning in irc that it is important that these xmlrpc exceptions are > untranslated.
Not really. I said, that we usually do not translate API exceptions. That means I know a few of them being translated, but there's not a strict requirement to have them localized. > Everything fine, however then I realized > ChannelSoftwareHandler uses CreateChannelCommand for creating channels, > and therefore it receives translated exceptions. > > EditChannelAction catches the exceptions and based on the reason > constructs ActionMessages no matter if the exception was already > translated or not. If I could use the translated ones, I could remove > the switch per-reason and just construct an ActionMessage directly from > the Exception. > > Any guidance here? Ideal case would be to work just with the "cause/description identified" and localize it just before the handover to the user (or not localize it - let's say according to a predefined option for API exceptions). However I know the most of our code is far away of it. Regards, Tomas -- Tomas Lestach RHN Satellite Engineering, Red Hat _______________________________________________ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
