Hi Jignesh,

I see, but I think is extremely easy to remove the "DyamicField_" prefix using 
a simple Regular Expression (for substitution), you can use it everywhere in 
your code even if the prefix is not there.

On the other hand, we have this prefix is some parts of the code in several 
files, because a Dynamic Field can be named as Priority, StateID, Owner, 
ResponsibleID, TicketNumber, etc. if you call TicketGet from the TicketObject 
and you don't have the "DynamicField_" Prefix in the Dynamic Fields it will be 
totally a mess. and it will be worst, if you for example update the ticket 
based on the results of a TicketGet (without the prefixes).

So IMHO I don't see many complications in having the prefix, but a lot of 
problems if we don't. Please think about it.
 
((enjoy))

Carlos Rodríguez




On Mar 20, 2013, at 9:21 AM, "Jignesh Kakka (jkakka)" <jka...@cisco.com> wrote:

> Hi Michiel,
>  
> Let’s say we add a dynamic field called ticket_source in OTRS.
> Now while creating the ticket , there is no problem.
> But while getting the ticket, I have to modify my application  source code to 
> get/read this new Dynamic field from the response.
> Had it been name-value pair, it would have got populated in my map 
> automatically.
>  
> Thanks,
> Jignesh
>  
> From: dev-boun...@otrs.org [mailto:dev-boun...@otrs.org] On Behalf Of Michiel 
> Beijen
> Sent: Wednesday, March 20, 2013 4:05 PM
> To: Development community of OTRS
> Subject: Re: [dev] Issues with Dynamic Fields
>  
> Hi,
> 
> On Wed, Mar 20, 2013 at 5:33 AM, Jignesh Kakka (jkakka) <jka...@cisco.com> 
> wrote:
> While creating ticket, we pass Dynamic fields as name-value pair. But while 
> getting ticket we receive dynamicFields as DynamicField_FieldName.
> Cant this behavior be changed to having Name Value pair even while getting 
> the ticket.
> The reason wh I want in this way is , let’s say if we add or remove a dynamic 
> field from System, then it may not require code change if we maintain as 
> name-value pair
> I was assuming that this may happen in OTRS 3.2 . But it also applies same 
> logic while getting tickets
>  
> Can you explain the use case you have for this? What code would you now write 
> that can be different if OTRS behaviour would change?
>  
> --
> Mike 
>  
> _______________________________________________
> OTRS mailing list: dev - Webpage: http://otrs.org/
> Archive: http://lists.otrs.org/pipermail/dev
> To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev

_______________________________________________
OTRS mailing list: dev - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/dev
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev

Reply via email to