good that you have read thrue the code of the involved packages.
Let me try to answer all of you questions:
4) Tests & Documentation:
Documentation and tests are a very important part of software development. In Open Source and especially in scripting languages you should start with it and have it published as early as possible. In some way the Documentation and Tests is your software design. For Plone Core Packages there should always be the order, Basic Documentation, definition of tests, implementing tests, implementing code.
That mean you should plan to spent at least 50 % of your time on documenting and testing.
But there is a hugh but: You most set that a high test coverage is wished, which is important on scripting languages due to have no feedback through a compiler. But 100 % Test coverage just says that all of your code has been executed once, but neither if it is correct or useful. Tests need to be also functional and test edge cases, so that it is more a design that just call everything once.
I know that I by myself most often does a lot of documentation and classical software design on paper before starting to implement, but that also means that my code has less tests and documentation necessary. I think RestrictedPython is a better example on which I work where you see how much energy should go into documentation and tests before implementing the software itself.
For this Project, we do have another special case, those addons under the namespace ploneorg.* are add-ons for the plone.org page and propably would not be used anywhere else, so time spend on tests and documentation in the first place was even worst than normal. But for a GSoC project we should follow or own standards and lift docuemntation and tests
1) Neither nor. The base was created by a mr.bob skeleton, but than the content types was clicked together TTW in a larger discussion of some people, afterwards it was transfered into the model XML and annotated with the addtional parts like security, widgets and so on.
If there is a standard way, well, there is the thing called "best practice" which follows the documentation in the training manual. But for the ploneorg packages, we do try to use the new suggested way that allows round trip development and so on. So it is also a test case for what should become the next "best practice", but is not at the moment.
I personally would prefer to use this new style with model XML implementation. But it does not need to be used, if you feel more comfortable with another documented way.
2) Browser views:
The base_view was a first test to implement a display view on an insatcne of an add-on object. Dexerity did generate a default view for all fields by it schema, but that gives a very large html page that is almost worthless, due to the large set of date coming from pypi, that we just consume. So that is just a reduced set of the fields to show at the moment and could be used as a starting point for implementing final browser views for the add-on class.
the update* views are temporary helper views that have go before an installation on plone.org as the would be a security risk. The do start an data import form pypi, by calling utils methods. Those calls should be reimplemented as command line commands, so taht a cron job could call them freqently. For now they just allow to make updates of the add-ons on a plone single instance setup.
* update_listing looks up any new plone add-on on pypi and import it into plone.org
* update looks up new data of an existing add-on in plone.org from pypi and updates the data
* update_all_listing goes through all add-ons already imported in plone.org and does a loop to call update on each add-on instance.
3) plone.vulnerabilitychecks.core does all the checks if a plone setup is vulnerable, but it itself does nothing. All the actual acting addons (instance_startup, buildout, tests) are wrappers around the core package to be used ins specific cases.
All three should go in the long turn into the plone unifiedinstaller to help people know about security problems
- p.v.buildout tells you at buildout time that the used setup will be vulnerable
- p.v.tests tells you on CI tests that this Plone version is either vulnerable and not patched
- p.v.instance_startup does either warn or explict disallow a vulnerably plone instance to start.
as p.v.instance_startup could be itself used as a denial of service element and kill a production setup, it should never be activated by default.
So having several of those allows Plone users to use one of those to check their setup frequently, for example by including p.v.tests into their CI pipeline.
I hope that helps you.