Ok. Will commit it without the proposed redundancy. There seems to be other
ways to do this as you mentioned. We'll figure that out once this is done.
Thanks.
- Chethiya
On Sat, Dec 1, 2012 at 1:49 PM, Senaka Fernando <sen...@wso2.com> wrote:
> Hi Chethiya,
>
> What I'm most concerned is the inconvenience to the user in here. I know
> that this would bring about a performance gain, but I think usability does
> win. However, we should not simply rule this out.
>
> Isn't there any other way to do this? What's the hit in having a single
> XPath check to figure out whether at least one attribute is set? Or, right
> now, the artifact payload is parsed at least once when we build the
> content. Can't we have an in-place validation. This would mean that the
> existence check for the validation is IIRC a fairly inexpensive,
> getAttribute call on the OMElement. Or is there a possibility to introduce
> some form of caching and improve this later on, and leave what we have at
> the moment?
>
> Thanks,
> Senaka.
>
> On Sat, Dec 1, 2012 at 1:40 PM, Chethiya Abeysinghe <cheth...@wso2.com>wrote:
>
>> Hi Senaka,
>>
>> On Dec 1, 2012 7:29 AM, "Senaka Fernando" <sen...@wso2.com> wrote:
>> >
>> > Hi Chethiya,
>> >
>> > Well my expectation was to do it in a way where each field will have an
>> attribute. If the attribute is present, we validate, if not we don't.
>> Therefore, this additional attribute sounds redundant to me. WDYT?
>>
>> Ya we have those attributes in each field in need of validation. This
>> attribute I'm talking about should be in a root level element and yes it is
>> redundant. But I'm suggesting this redundancy for an optimization. I.e not
>> to iterate through the XML to find fields with validation when there is an
>> indication at the top saying not to do so.
>>
>> Why we need to decide this now is if we don't put this attribute now, we
>> will be in trouble providing backward compatibility, in case we will need
>> to add this attribute later.
>>
>> BTW currently add artifact method loads every rxt, parse all, matches the
>> one with required key, then load required data from it to a configuration
>> object by iterating. Possible optimization for these expensive operations
>> are using a bounded cache. In such a case we alternatively can generate
>> boolean called doValidation when loading the configuration to the cache.
>>
>> In such a case this attribute is not really necessary to be in the rxt.
>> But if this is not a problem for the rxt writer, having this redundancy is
>> the optimal!
>>
>> - Chethiya
>>
>> >
>> > Thanks,
>> > Senaka.
>> >
>> >
>> > On Sat, Dec 1, 2012 at 1:22 AM, Chethiya Abeysinghe <cheth...@wso2.com>
>> wrote:
>> >>
>> >> I'm planning to put $subject as an optimisation for API calls when
>> adding artifacts. When adding artifacts that belong to an RXT with this
>> attribute is "false" (or not present - for backward compatibility), will
>> processed faster bypassing the check. Otherwise there will be a recursive
>> iterator going through the RXT searching for fields with validation regex
>> and doing regex matching, for each addArtifact operation.
>> >>
>> >> The only problem I have at the moment is the line 55:
>> >>
>> >> OMElement head =
>> uigen.getUIConfiguration(client.getArtifactUIConfiguration(request.getParameter("key")),request,config,session);
>> >>
>> >> in
>> >>
>> >>
>> platform/branches/4.0.0/components/governance/org.wso2.carbon.governance.generic.ui/4.0.5/src/main/resources/web/generic/add_edit.jsp
>> >>
>> >> And similarly edit_ajaxprocessor.jsp too.
>> >>
>> >> Here getArtifactUIConfiguration() only extracts the <content> element
>> of the .rxt.
>> >>
>> >> One solution is to put this optional "doValidation" attribute to
>> <content> element as at BE OMElement for <content> is anyway created. Is
>> this viable? I don't see any attribute in this element yet too.
>> >>
>> >> Another solution for this is to add a new method
>> to ManageGenericArtifactService.java which is in
>> org.wso2.carbon.governance.generic. This will extract the content of the
>> actual .rxt resource.
>> >>
>> >> Thanks
>> >> --
>> >> Chethiya Abeysinghe
>> >> Software Engineer; WSO2, Inc.; http://wso2.com/
>> >> email: cheth...@wso2.com
>> >> blog: chethiya3000.blogspot.com
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> >
>> >
>> > Senaka Fernando
>> > Member - Integration Technologies Management Committee;
>> > Technical Lead; WSO2 Inc.; http://wso2.com
>> > Member; Apache Software Foundation; http://apache.org
>> >
>> > E-mail: senaka AT wso2.com
>> > P: +1 408 754 7388; ext: 51736; M: +94 77 322 1818
>> > Linked-In: http://linkedin.com/in/senakafernando
>> >
>> > Lean . Enterprise . Middleware
>> >
>>
>>
>
>
> --
> * <http://wso2con.com/>
> *
> *
>
> Senaka Fernando*
> Member - Integration Technologies Management Committee;
> Technical Lead; WSO2 Inc.; http://wso2.com*
> Member; Apache Software Foundation; http://apache.org
>
> E-mail: senaka AT wso2.com
> **P: +1 408 754 7388; ext: 51736*; *M: +94 77 322 1818
> Linked-In: http://linkedin.com/in/senakafernando
>
> *Lean . Enterprise . Middleware
>
_______________________________________________
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev
