Re: rough edges

Op 25 mei 2012, om 15:32 heeft Andy Altepeter het volgende geschreven:

> 
> Hi,
> 


  Hello,

  [...]

> 
>>> zeam
>>> ====
>>> 
>>> * zeam forms (the<form>  tag) has no 'name' or 'id' attribute.  As such it impossible to test
>>> zeam forms using infrae.testbrowser's "get_form" method.  I have a local clone and branch of zeam, and have adjusted some of the form templates to simply put the form prefix as the name attribute.  Not the best, but quick enough to enable writing of functional tests using infrae.testbrowser.
>>> 
>>    They should have a name, in 2.3. That's how I test it using infrae.testbrowser, and there is rather correct functional testing suite in 2.3 (compared to before), so I am sure of it. If name is missing in some the templates, you should have posted it on the mailing list, and I would have gladly fixed it (or sent me a patch).
> 
> Sure.  zmisubformtemplate is missing a 'name' attribute.  You can see my patch here:
> https://hg.infrae.com/zeam.form.silva/rev/47b1b129f46e

   This is fixed, sorry.

>>> * If a zeam form fails to initialize you get a 404 Not Found, and no error is
>>> recorded in the error log.  Example: a custom composed form with an __init__
>>> that creates subforms based on criteria other than adapters, i.e. a subform
>>> for each value of a property on the content object.  If the __init__ fails, a 404 is raised.
>>> 
>>   Yes, that's a limitation of Zope. In Zope, views are adapters. They you have an exception raised in an __init__ of an adapter, the ZCA raise a ComponentLookupError (same exception that is raised when no adapter is found). This is translated to a 404 not found in case of a view.
>> I as well hate this feature, if you can call it feature, and lost many hours because of it. This is not specific to zeam form or Silva.
>> 
>>   If you wish to change the subforms, and that your are not sure that your code won't trigger errors, I would recommend doing it in update, before calling the super() to the call the update of the Composed form (that will call update on the sub-forms). This will be done before any form business is done (which is handled by updateForm and called after update).
> Thanks for the explanation.  It's sad but encouraging to hear you have struggled with it too. The approach I took is a pattern I developed about a year ago.  I don't recall the full specifics, but I tried doing this in the update form (replacing the subforms with a custom list) and it didn't work.

   There is not much I can do about the views. From the composed form point of view, I could move the collection of the sub forms into a a different method so you can override it. I will think about it, but in that case the subforms grokkers becomes useless (meaning useless work is done).

>>> * what is a field / widget to use to manage an arbitrary set (of strings)?
>>> I want to be able to add strings to the set and remove strings from the
>>> set.  I thought a textarea would work, but I ended up creating a custom
>>> DataManager to convert the text area value into a set and back into
>>> a list.  I see that the tuple schema field has a difficult to use UI, is there something better?
>>> 
>>   Kit asked me to create a 'lines' widget. It is located in zeam.form.silva (use. mode = 'lines' on your zeam field). The correct fashion for this would be to create a widget, that extract to the correct type of data (a set of string). DataManager have the only responsibility of setting (and getting, deleting now) the value on the content, when the content is an object, or a dictionary, or a reference.
> I tried setting mode="lines" in with a schema.Tuple having a value_type of schema.URI, and I received a componentlookuperror.  I agree the "correct" way would be to create a new widget and widget extractor for this one thing.

  Yes, the field is available for a collection of textline. I just registered it as well for collection of URIs (please check the trunk of zeam.form.silva, widgets/other.py).

>>> infrae.wsgi
>>> =======
>>> 
>>> * I would like ability to write to the error log from code sources while swallowing the error (if a CS has an error, the page should still display)
>>> 
>>   This is fixed in 3.0, and was regarded as a bug. And there is a function you can call if you wish to add errors to the error log, it is possible.
> Was this a fix in infrae.wsgi, or where else?  Can it be used in Silva 2.3, or back-ported?

   This is a function that is used in Products.SilvaExternalSources to log changes using infrae.wsgi log facilities. Yes it can be used in 2.3 (3.0 works with the same version of infrae.wsgi than 2.3, recent changes are just to support new extensions like the alternative virtual hosting manager).

   This is log_last_error from infrae.wsgi.log.

   I have to check, I have the feeling that the logging went away from the code sources in the last refactoring I did in 3.0.

>>> * I would like ability to add additional exceptions to ignore in a
>>> persistent manner, e.g. in zope.conf or something.  The old zope error log
>>> also recorded a full suite of data about an error; all we get is a short list
>>> of state variables and a traceback. I usually find the recorded state to be
>>> insufficient.  It would also be nice to be able to have more than 25 errors in
>>> the log, and an improved errorlog view (collapsible errors?) would also be helpful.
>>> 
>>> Basically, I miss the old zope error log :-)
>>> 
>>   I didn't use the Zope error log because:
>> 
>>   1. There is far less information written in the filesystem log, and that is the information that our customers provides us with. Now you have the URL, referer, user, the various published Zope objects in this log. Before you only had a traceback without context.
>> 
>>   2. Using the log through the web interface is not really useful, as far as I think, because even the Zope error log only keep the latest errors, and usually not the most interesting ones.
>> 
>>   2. When you have an error logged in the Zope error log, it often create a commit (even if the error is not stored in the database). Having lot of errors creates conflict errors, that bring down the site, even if parts of it works.
>> 
>>   3. Lot of information is lost in the Zope error log. It actually going through 5 or 6 different API, loosing and replacing correct information with wrong one, and at the end, when it renders the error message to the user, well you don't always have the correct context, error, message. Having correct error pages is more important to me than a buggy, anyway unusable error log that is the Zope one.
>> 
>>   4. Going through all those API make rendering an error absolutely slow.
>> 
>>   But for sure, we can improve the current web interface, and make the list of exception to ignore configurable. I already thought of that, some customers have extra exceptions they want to be ignored as well, but never got the time to do it.
> I agree with all of what you say about the old error log.  From a consultant stand point it really makes sense.  But from a silva manager standpoint, the old error log was nice.  A richer set of context data for each error, improvements to ignored exceptions, and a nicer UI would be much appreciated.

  I will improve it.

>>> Writing tests
>>> ========
>>> 
>>> 


[...]

> Partly my point was to say that the Silva framework is huge and while single apis are typically designed ok, digging through them all to find the one pattern I'm looking for, which I need in order to test what I actually want to test, is a pain.  I disagree with the "your api sucks" comment.  Even your new functional tests have helper functions to do things that are common in the ui (like add an object) -- does that mean your UI sucks?  Or the api layer for the browser?  No, perhaps it's just a common pattern that has an irreducible number of steps.  I think the same happens in unittests.  One would hope that, as an api drifts, the tests would break and need to be adjusted anyways...
> 

  I say that, because I want my test to test my code, and not my helpers. I am tired of fixing endless bugs, that where never detected because of that, and that was specially true with old the test helpers provided in Silva, I think.

> Perhaps a better example is the old addObject helper method. I really like that as it makes the testing code uniform and simple.  I have put copies of it in most of my test suites.

  You can still do it, in your code. The fact is for I don't think it is much more work to call the factory, than to add methods on the test case, and after by reading the code, I directly know what is done, and what is tested, and don't have to juggle with multiple files, and multiple functions  or methods.

  Regards,

  Sylvain,

-- 
Sylvain Viollon -- Infrae
t +31 10 243 7051 -- http://infrae.com
Hoevestraat 10 3033GC Rotterdam -- The Netherlands