Re: [Framework-Team] Kicking off Plone 4: Release Manager candidate

[whit]

is there some sort of voting process for release manager now? in the
past, the board has just picked a manager and sometimes even paid them
;)

-w

-- 
  <=>
 david "whit" morriss
 opengeo -- http://opengeo.org

 "If you don't know where you are,
  you don't know anything at all"

  Dr. Edgar Spencer, Ph.D., 1995

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: What is Plone 3.3?

[whit]

it gives me warm fuzzies to see the harmonious accordance of prudence :)

-w

On Mon, Oct 13, 2008 at 11:27 PM, Alexander Limi <[EMAIL PROTECTED]> wrote:
> On Sat, 11 Oct 2008 08:47:51 -0700, Martin Aspeli <[EMAIL PROTECTED]> wrote:
>
>> Right now, the things that concern me are:
>>
>>  - Adding a new way to add content (the "add sibling" proposal)
>>  - Moving the contextual "manage portlets" link somewhere else
>>  - Removing the "display" menu and putting the behaviour on the fieldset
>>
>> (the last one is doubly bad, because it would require any add-on product
>> that used this menu to be updated in a possibly backwards-incompatible way,
>> to add a field to replicate this, and we'd need a unique solution for non-AT
>> content).
>
> +1, I don't think any of these should land in 3.x. Especially since a lot of
> them should hopefully be moot in the next major release anyway — but in the
> meantime, let's not change UI behaviour in a minor release. It's bad form,
> and while I'm usually tending towards this, I have changed my approach after
> seeing the confusion it can cause.
>
>> Luckily, there's a "workaround". :) All of these changes could be provided
>> with easy-to-install add-on products. These could be tested on real users
>> and used by those who want different behaviour.
>
> This is the way to go if you want your pet UI peeve addressed in the 3.x
> series.
>
> Thanks for raising this, Martin.
>
> --
> Alexander Limi · http://limi.net
>
>
> ___
> Framework-Team mailing list
> Framework-Team@lists.plone.org
> http://lists.plone.org/mailman/listinfo/framework-team
>



-- 
  <=>
 david "whit" morriss
 opengeo -- http://opengeo.org

 "If you don't know where you are,
  you don't know anything at all"

  Dr. Edgar Spencer, Ph.D., 1995
___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: availability over the next 5 months

[whit]

I should probably report that I checked out awhile ago and have been
doing next to no plone work (not much free time to devote to code
outside of work, and not doing plone at work currently).  As one of my
pet peeves when I was doing plone work was folks who abandoned their
children, so I'd like to help orchestrate a more graceful passing of
the torch for wicked than just letting it drift into abject neglect. I
don't to dump this on rob miller lap by default, or create any sort of
linger expectation about my role.

the point of this is if anyone is interested, I would be glad to help
them get up to speed stewarding this project (and perhaps setting up
proper support for it). we could also come up with a roadmap for know
issues, improvements etc.

wicked is a mixed bag: with newer technology, there are much more
graceful ways to do wicked that would require much less code.   the
current design has some fairly limiting flaws and alot of room to
improve.   it exhibits the hallmarks of many early fivish apps where
components  are used like a hammer and everything is a nail that can
be abstracted. There is some good stuff in there too (I think the
fieldevent pattern is pretty powerful) that sadly I haven't had the
time to really properly document or make howto's to demonstrate usage.

so if you are interested, just let me know(with a direct reply).

-w

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Framework Team membership, release manager, roles and responsibilities

[whit]

On Wed, Feb 27, 2008 at 4:25 AM, Graham Perrin <[EMAIL PROTECTED]> wrote:
> > From: Andreas Zeidler <[EMAIL PROTECTED]>
>  > Date: 26 February 2008 23:46:24 GMT
>  > To: George Lee <[EMAIL PROTECTED]>
>  > Cc: framework-team@lists.plone.org
>  > Subject: Re: [Framework-Team] Re: WebDAV changes
>  >
>  > On Feb 24, 2008, at 9:51 PM, George Lee wrote:
>  >
>  >> P.S. I think that as a matter of process it make sense that a
>  >> release manager can make / ask for a major revert for time's sake,
>  >> but that the framework team should then speak up on that because
>  >> ultimately it's supposed to be their decision and what they're
>  >> accountable for.
>  >
>  > no, not really.  the framework team's job is to review and give
>  > recommendations to the release manager.  the decision to merge or
>  > not to merge (or revert for that matter) is made by the release
>  > manager, though.
>  >
>  > cheers,
>  >
>  >
>  > andi
>  >
>  > ps: also see http://plone.org/development/teams/framework/faq
>
>  1) <http://plone.org/development/teams/framework/framework-team>
>  states that
>
>  > The Framework team is only responsible to accept/reject PLIPs
>
>  -- to me, that sounds like decision making ;)

but of something completely different.

>  OK so the preceding paragraphs, and <http://plone.org/development/
>  teams/framework/faq>, are more explicit, but <http://plone.org/
>  development/teams/framework/framework-team> in its entirety could be
>  misinterpreted.

framework team was never intended to make any decisions beyond
recommendations to the release manager on what to include in a
release.  This was part of the big reason to choose new members after
making the recommendation so the community would not mistake the power
of the framework team as extending beyond making recommendations and
acting as the gatekeeper for plips and the code associated with them.
  Choosing new members frees up FWT members to work on the release
without any confusion by the wider community about them still making
decisions about what goes in release.

the framework team wasn't intended to be a primary decision making
body, but to aid to the release manager, who can take or leave what
the framework team recommends and has the latitude to make any
necessary decisions outside of those recommendation.

it seems this time around time obligations for review were a bit of a
problem. for next, I want to bring up an old option, the external
review. As long as the FWT makes sure someone relatively unbiased
reviewed the PLIP and voted on it, it didn't matter who did the
reviewing.  the main thing is someone conscientiously looks at the
code and writes a coherent review.Maybe next time around it would
be worthwhile to line up a few extras ahead of time to review code in
case of life offline happening ;)

-w





-- 

 | david "whit" morriss
 |
 | contact :: http://public.xdi.org/=whit

 "If you don't know where you are,
  you don't know anything at all"

  Dr. Edgar Spencer, Ph.D., 1995


 "I like to write code like
 other ppl like to tune their
 cars or 10kW hifi equipment..."

 Christian Heimes, 2004

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Is this thing on?

[whit]

hey, if the werewolf wants to be on the framework team I say more the
merrier ;)

On Nov 20, 2007 2:17 PM, Martin Aspeli <[EMAIL PROTECTED]> wrote:

> Wichert Akkerman wrote:
> > That should have gone to Martijn Pieters instead of Martijn Faassen. :)
>
> Sorry Martijns!
>
> Martin
>
>
> ___
> Framework-Team mailing list
> Framework-Team@lists.plone.org
> http://lists.plone.org/mailman/listinfo/framework-team
>



-- 

| david "whit" morriss
|
| contact :: http://public.xdi.org/=whit

"If you don't know where you are,
 you don't know anything at all"

 Dr. Edgar Spencer, Ph.D., 1995


"I like to write code like
other ppl like to tune their
cars or 10kW hifi equipment..."

Christian Heimes, 2004
___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] New team

[whit]

yeah, the formal process last time mainly involved me picking people with
some input from alecm and others. so any process would probably be more
formal ;)

-w

On 10/29/07, Martin Aspeli <[EMAIL PROTECTED]> wrote:
>
> Hi all,
>
> Now that we're talking seriously about Plone 3.1, we need a new
> Framework Team.
>
> We've already had one nomination, but we need at least 5 people in
> total. I don't see a problem with any existing members staying on, nor
> with past members making a comeback, but fresh faces are appreciated.
>
> I'd like to solicit nominations (please talk to the person first) and
> volunteers. Please either respond here or email me in private.
>
> I'm not sure if we have a formal process (last time, we just asked
> around and arrived at a consensus), but I was thinking to email the
> existing members in private and have them vote on the new team.
>
> Martin
>
> --
> Author of `Professional Plone Development`, a book for developers who
> want to work with Plone. See http://martinaspeli.net/plone-book
>
>
> ___
> Framework-Team mailing list
> Framework-Team@lists.plone.org
> http://lists.plone.org/mailman/listinfo/framework-team
>



-- 

| david "whit" morriss
|
| contact :: http://public.xdi.org/=whit

"If you don't know where you are,
  you don't know anything at all"

  Dr. Edgar Spencer, Ph.D., 1995


"I like to write code like
other ppl like to tune their
cars or 10kW hifi equipment..."

Christian Heimes, 2004
___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] post-3.0: tags? branches?

[whit]

pinning seems pretty sane and makes it easy to convince a package maintainer
to branch or tag from a particular revision if maintenance branches make
sense.

-w

On 8/13/07, Wichert Akkerman <[EMAIL PROTECTED]> wrote:
>
> With 3.0-final coming up I have been wondering how to handle the 3.0
> bundle. I would like to have this bundle be as stable as possible, which
> suggests that it ca not keep using trunks everywhere. But most products
> and packages will not have a seperate stable branch for their current or
> upcoming release either. So what to do?
>
> One option I've been pondering is to update the bundle to use tags or
> revision pins for any package or product which does not have a seperate
> maintenance branch. Possible that is a somewhat extreme thing to do
> though.
>
> I would like to hear some opinions on this before I make any decisions.
> So... what do you think?
>
> Wichert.
>
>
>
> --
> Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things.
> http://www.wiggy.net/   It is hard to make things simple.
>
> ___
> Framework-Team mailing list
> Framework-Team@lists.plone.org
> http://lists.plone.org/mailman/listinfo/framework-team
>



-- 

| david "whit" morriss
|
| contact :: http://public.xdi.org/=whit

"If you don't know where you are,
  you don't know anything at all"

  Dr. Edgar Spencer, Ph.D., 1995


"I like to write code like
other ppl like to tune their
cars or 10kW hifi equipment..."

Christian Heimes, 2004
___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

[Framework-Team] Re: [Plone-developers] wicked stuff

[whit]

got a dual pattern filtering working locally  yesterday. will release 
for rc2.


-w


--

-- d. whit morriss --
- senior engineer, opencore -
- http://www.openplans.org  -
- m: 415-710-8975   -

"If you don't know where you are,
 you don't know anything at all" 



Dr. Edgar Spencer, Ph.D., 1995


___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

[Framework-Team] Re: [Plone-developers] wicked stuff

[whit]

Martijn Pieters wrote:

On 7/17/07, whit <[EMAIL PROTECTED]> wrote:

Martijn Pieters wrote:
>def chunks(self):
> chunks = super(WickedFilter, self).chunks
> # every 2nd entry is the parens group, so filter out by
> # grabbing every 1st and 3rd
> firsts = itertools.islice(chunks, 0, None, 3)
> thirds = itertools.islice(chunks, 2, None, 3)
> result = []
> # then append every 1st and 3rd to a list
> map(result.extend, itertools.izip(firsts, thirds))

any difference between this and:

for slice in itertools.izip(firsts, thirds):
 result.extend(slice)



Nothing, the code grew a bit and wasn't finished. :) There is a if
len(chunks) <= 1: return chunks missing there too, for example.


there may be a simpler juncture for getting the desired effect.

the filter is run by a subscriber, and running it twice (once for each
desired pattern) would be trivial, rather than pushing additional
complexity into the filtering classes.  This would happen for both the
findall call that is part of the storing event and the split call that
is part of rendering.

Plone would use these special subscribers and if folks just wanted
either/or behavior, they could disable them and use the old subscribers.


I am not too familiar with the subscribers, but that sounds like a
fine plan to me.
subscribers handle all the action on render or on store.  iirc, it's 
just a matter of setting the pattern before each run of the filter and 
clearing the memos. 



I am assuming the current UI uses a radio select (format a *or* format
b). You could change this to a set of checkboxes. Replacing the
subscriber with one that runs either filter based on those selection
boxes would get you the same effect, no?

iirc, the whole point of this was so limi could have an interface where 
one could turn on or off wiki linking(no other choices).  I assume after 
this is solved, thats' what will happen.


-w

--

-- d. whit morriss --
- senior engineer, opencore -
- http://www.openplans.org  -
- m: 415-710-8975   -

"If you don't know where you are,   
you don't know anything at all" 


Dr. Edgar Spencer, Ph.D., 1995

begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
org:The Open Planning Project;OpenPlans
adr:;;1309 Ashwood Ave;Nashville;TN;37212;USA
email;internet:[EMAIL PROTECTED]
title:Lead Developer 
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

[Framework-Team] Re: wicked stuff

[whit]

Martijn Pieters wrote:

On 7/16/07, Martijn Pieters <[EMAIL PROTECTED]> wrote:

If the one-group limitation were removed, the pattern would be:

pattern = re.compile(
# Opening brackets or parens
r'(?: (?P\(\() | \[\[ )'

r'(?P [\w\W]+?)'  # the text between the
brackets or parens)

# Closing brackets or parens
r'(?(parens) \(\( | \[\[)', re.X)

which will have a 'parens' and a 'text' group, and split and findall
will have to be re-thought.


Looking at the code, I realized we could easily do this in the
WickedFilter class. The following overrides would help us deal with
the additional pattern information:

import itertools

def findall(self, value):
result = []
for groups in super(WickedFilter, self).findall(value):
result.append(groups[1])
return result

   def chunks(self):
chunks = super(WickedFilter, self).chunks
# every 2nd entry is the parens group, so filter out by
# grabbing every 1st and 3rd
firsts = itertools.islice(chunks, 0, None, 3)
thirds = itertools.islice(chunks, 2, None, 3)
result = []
# then append every 1st and 3rd to a list
map(result.extend, itertools.izip(firsts, thirds))


any difference between this and:

for slice in itertools.izip(firsts, thirds):
result.extend(slice)

?

return result

I still have to deal with the fact that super(WickedFilter,
self).chunks doesn't actually work (it's a property), but I can work
that out too. Should I continue down this path?

Once this works, you can mix [[one format]] with the ((other format))
in one document.



there may be a simpler juncture for getting the desired effect.

the filter is run by a subscriber, and running it twice (once for each 
desired pattern) would be trivial, rather than pushing additional 
complexity into the filtering classes.  This would happen for both the 
findall call that is part of the storing event and the split call that 
is part of rendering.


Plone would use these special subscribers and if folks just wanted 
either/or behavior, they could disable them and use the old subscribers.


I'll take a look at this tomorrow.

-w



--

-- d. whit morriss --
- senior engineer, opencore -
- http://www.openplans.org  -
- m: 415-710-8975   -

"If you don't know where you are,
 you don't know anything at all" 



Dr. Edgar Spencer, Ph.D., 1995


___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: wicked stuff

[whit]

Alexander Limi wrote:
On Sun, 15 Jul 2007 19:16:17 -0700, Alexander Limi <[EMAIL PROTECTED]> 
wrote:


Related, I hope I didn't break any doctests by cleaning up the 
markup, I was unable to run the tests — here's the output I got when 
I tried:


After installing lxml and invoking the tests differently, I get 
closer, but still no cigar:


$ bin/zopectl test --package wicked



Running Products.PloneTestCase.layer.ZCML tests:
  Set up Products.PloneTestCase.layer.ZCML in 3.909 seconds.
  Running:
..python(1419) malloc: ***  Deallocation of a pointer not 
malloced: 0x80; This could be a double free(), or free() called with 
the middle of an allocated block; Try setting environment variable 
MallocHelp to see tools to help debug
can elementree apply xslt? if so, it would be trivial to remove the 
dependency on lxml in the wicked tests(it's basically just used for 
formatting output).


On mac, with lxml, I find I have to set the following to avoid errors 
with recent lxml (my libxml is installed in fink)::


export DYLD_LIBRARY_PATH="/sw/lib"

-w

--

-- d. whit morriss --
- senior engineer, opencore -
- http://www.openplans.org  -
- m: 415-710-8975   -

"If you don't know where you are,   
you don't know anything at all" 


Dr. Edgar Spencer, Ph.D., 1995

begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
org:The Open Planning Project;OpenPlans
adr:;;1309 Ashwood Ave;Nashville;TN;37212;USA
email;internet:[EMAIL PROTECTED]
title:Lead Developer 
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

[Framework-Team] Re: wicked stuff

[whit]

Alexander Limi wrote:



On Tue, 10 Jul 2007 12:12:13 -0700, whit 
<[EMAIL PROTECTED]> wrote:



I also added multiple pattern support( ie [[]] or (()) ).  Whichever
pattern matches first is used for the whole block of text.  I'm not sure
this is the preferred behavior, but it was much faster to implement(and
the code is easier to read than the regexes).  Perhaps someone knows an
alternating regex that will work with the existing code.


This confused me at first, since one of the formats was working, but 
not the other — and until I read your post, I didn't understand why. I 
guess it's unlikely to come up in real-life, but people on plone-dev 
(CCed) know a regexp that would match on both. :)
if someone has one that will work, great. from my experience, matching 
alone doesn't quite cut it, but as stated in my post, if someone has a 
regex that will actually work for the code, I would be glad to use it. 


I also tried slimming down the markup and making it consistent with 
how other wikis work, as well as the Plone link class standard 
(non-existant pages are red, add links have the entire link clickable, 
but with a superscript "+" etc).


The one thing I'd like to know is whether the ID hashes are actually 
used for anything, or whether they can be removed, example:



  contact the Plone Team

this was added with the intention of creating ajax interfaces for 
adding.  it can be removed, or preferably, overridden.


I'd like to get rid of the stray  tag, so either putting the id 
on the link tag itself — or remove it altogether if it isn't used — 
any comments on whether this would break anything?



should be fine.

-w

--

-- d. whit morriss --
- senior engineer, opencore -
- http://www.openplans.org  -
- m: 415-710-8975   -

"If you don't know where you are,   
you don't know anything at all" 


Dr. Edgar Spencer, Ph.D., 1995


___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: wicked stuff

[whit]

I stole from createObject, then from some pf code in opencore, but I'm 
mystified why neither works.


I'd suggest that we leave this issue open but downgrade. Arguably, it 
should never have been critical in the first place.


sounds good to me.  hopefully soon things will move away from ol'pf.

-w

--

-- d. whit morriss --
- senior engineer, opencore -
- http://www.openplans.org  -
- m: 415-710-8975   -

"If you don't know where you are,   
you don't know anything at all" 


Dr. Edgar Spencer, Ph.D., 1995

begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
org:The Open Planning Project;OpenPlans
adr:;;1309 Ashwood Ave;Nashville;TN;37212;USA
email;internet:[EMAIL PROTECTED]
title:Lead Developer 
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

[Framework-Team] wicked stuff

[whit]

Martin Aspeli wrote:

Hi Whit,

In the interest of getting releases out ... do you have any comment on 
https://dev.plone.org/plone/ticket/6284?


Martin

a couple(nouri looked at this a while a back and I've been playing with 
it yesterday and today).



Technical comments::

I hacked together something that should work afaict, except I get 
non-deterministic traversal errors for the portal_factory in the tests::


excerpt:
   new_content = 
self.context.restrictedTraverse('portal_factory/%s/%s' % (type_name, id_))
 File 
"/Users/whit/dev/env/p3/src/ploneout/parts/zope2/lib/python/OFS/Traversable.py", 
line 301, in restrictedTraverse

   return self.unrestrictedTraverse(path, default, restricted=True)
 File 
"/Users/whit/dev/env/p3/src/ploneout/parts/zope2/lib/python/OFS/Traversable.py", 
line 269, in unrestrictedTraverse

   raise e
   KeyError: 'ATContentTypes Topic: Add ATBooleanCriterion'

And in the browser, ArchivistUnregisteredError for the piece of content 
I'm trying to edit.  Nouri reported issues with the creation of the  
backlink (at) references; not sure if I got that far.


I checked in a drop-in replacement view that would use PF for content 
creation, so maybe someone with more pf foo can figure this one out: 
http://tinyurl.com/yvm8fd. 

You can activate it by uncommenting this reg: http://tinyurl.com/2dkz5x 
(and of course commenting the corresponding one).



Less Technical::

(why I'm less than motivated to invest more time in pursuing #6284)

1. the general wiki usage pattern and the plone security model make the 
possibility of creation of unwanted content rather low.  Most people use 
wiki links to rapidly layout a set of pages they want created whether 
they follow the links or not.  Creating empty pages in a wiki is 
creating a structure (content with ids and titles) to be filled in 
rather in contrast to the the result of random clicking of an add item 
button or menu and creating a un-titled, id-less document.


2. After running wicked at opencore for almost 2 years, we've never had 
a complaint or issue with this.  It may be slightly "bad form" but 
pragmatically, I not sold that it's worth the time mucking with pf.


3. inline adding via kss (or proper addviews for plone and/or at) are 
probably the next step for wicked links, making this pf dance irrelevant 
in the future.



I also added multiple pattern support( ie [[]] or (()) ).  Whichever 
pattern matches first is used for the whole block of text.  I'm not sure 
this is the preferred behavior, but it was much faster to implement(and 
the code is easier to read than the regexes).  Perhaps someone knows an 
alternating regex that will work with the existing code.


some variations that did not:

\(\(([\w\W]+?)\)\)|\[\[([\w\W]+?)\]\]

[\[\(][\[\(]([\w\W]+?)[\)\]][\)\]]

(?:\[\[)|(?:\(\()([\w\W]+?)(?:\)\))|(?:\]\])

-w


--

-- d. whit morriss --
- senior engineer, opencore -
- http://www.openplans.org  -
- m: 415-710-8975   -

"If you don't know where you are,   
you don't know anything at all" 


Dr. Edgar Spencer, Ph.D., 1995

begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
org:The Open Planning Project;OpenPlans
adr:;;1309 Ashwood Ave;Nashville;TN;37212;USA
email;internet:[EMAIL PROTECTED]
title:Lead Developer 
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] plone.theme - one more package for Plone 3?

[whit]

Martin Aspeli wrote:

Hi guys,

David, Florian and I were discussing the skinning story in Plone 3. 
David was a bit frustrated trying to customize things like the portal 
logo in a clean way. We made some headway, but discovered that it 
wasn't very easy to make use of Zope 3 browser layers in Plone.


For those not familiar with them, browser layers are markers which are 
applied to the request during traversal. You can register views, 
viewlets etc for a particular layer marker, either to override a view 
for a particular skin/theme, or to make sure a particular viewlet is 
only shown in a particular skin/theme.


For example:

 

This will only show up if the IMyTheme skin/browser layer is applied.

The most obvious way for this to would be for IMyTheme to correspond 
to a particular theme/skin as selected in portal_skins.


That's where plone.theme comes in. It provides an event handler 
listening to IBeforeTraverseEvent, and will attempt to match a browser 
layer marker to the current skin selection.


To use it, let's say you have "My Theme" in portal_skins. You could 
then have a marker interface like:


from zope.publisher.interfaces.browser import IDefaultBrowserLayer

class IMyTheme(IDefaultBrowserLayer):
"""Marker interface used in the tests
"""

and in configure.zcml:



The trick here is that the name of the IBrowserSkinType utility 
matches the name of the skin selection/theme in portal_skins.


The code is here:

  http://dev.plone.org/plone/browser/plone.theme/trunk/plone/theme

It's pretty simple, and there are (doc)tests. It should be pretty low 
risk.


Now, nothing in Plone core uses this (though NuPlone could use it, 
perhaps). I can release this to the Cheese Shop and things like 
DIYPloneStyle can depend on it. However, it may be useful to 
integrators and customisers if this is part of the Plone 3 
distribution, and its ZCML was loaded from Products/CMFPlone to avoid 
slugs or needing to include it explicitly.


I can manage the release and add it to the lib bundle and ploneout, if 
no-one objects to it going in at this (admittedly late) stage.


Martin


I would say this point you are at wiggy's mercy.

-w


--

-- d. whit morriss --
- senior engineer, opencore -
- http://www.openplans.org  -
- m: 415-710-8975   -

"If you don't know where you are,   
you don't know anything at all" 


Dr. Edgar Spencer, Ph.D., 1995

begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
org:The Open Planning Project;OpenPlans
adr:;;1309 Ashwood Ave;Nashville;TN;37212;USA
email;internet:[EMAIL PROTECTED]
title:Lead Developer 
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: five.intid compatible with five.localsitemanager

[whit]

I'm guessing he want to install the intid utility with full lsm 
capabilities.


-w

--

-- d. whit morriss --
- senior engineer, opencore -
- http://www.openplans.org  -
- m: 415-710-8975   -

"If you don't know where you are,
 you don't know anything at all" 



Dr. Edgar Spencer, Ph.D., 1995


___
Framework-Team mailing list
[EMAIL PROTECTED]
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: five.intid compatible with five.localsitemanager

[whit]

Martijn Faassen wrote:

whit wrote:
[snip]

I take this opportunity to bitch that I hate
viewcvs, the collective has trac and normal http browsing and often 
is faster than zope's repository and is not plone specific.  And 
having to use ssh + svn sucks for creating developer bundles or doing 
developer checkout view easy_install.  who should I be sending mail 
to at the ZF?


Your ZF developer board delegate is here and is listening. :)

Are you volunteering to do the work of setting up a trac for zope.org? 
We clearly have part of the functionality of Trac on launchpad, but I 
think for instance a trac timeline and browsing facility would still 
be very useful.


Moving the current infrastructure over to some new system would take 
quite a bit of doing (and not only technically), but if we got 
volunteers to help, we might actually get the ship in motion.


Regards,

Martijn
I'd be willing to help if it helps (note minimum effort was why 
five.intid went into the collective in the first place though).  I'm 
tolerant enough of a situation that makes me less inclined to contribute 
to zope ... so don't expect a champion or a martyr here.


if you can list what needs to happen and I'll see what I can do but as 
stated I'm too old and tired for any heroics.  if you could enumerate a 
process for the non-technical side(approvals needed, hardware needed, 
access needed, etc), it might help the next someone offers (however half 
heartedly) to help. you know, keep the bar low, make meaningful 
contribution easy as possible.


grumpily yours,

-w

--

-- d. whit morriss --
- senior engineer, opencore -
- http://www.openplans.org  -
- m: 415-710-8975   -

"If you don't know where you are,   
you don't know anything at all" 


Dr. Edgar Spencer, Ph.D., 1995

begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
org:The Open Planning Project;OpenPlans
adr:;;1309 Ashwood Ave;Nashville;TN;37212;USA
email;internet:[EMAIL PROTECTED]
title:Lead Developer 
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
[EMAIL PROTECTED]
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: five.intid compatible with five.localsitemanager

[whit]

sure maybe?

since I own five.intid, I take this opportunity to bitch that I hate 
viewcvs, the collective has trac and normal http browsing and often is 
faster than zope's repository and is not plone specific.  And having to 
use ssh + svn sucks for creating developer bundles or doing developer 
checkout view easy_install.  who should I be sending mail to at the ZF?


all bitching aside, +1 let's move it ;)  what needs to happen here?

Ross, let me know if there is anything I can do to help you with a 
release(or if you need me to make one).  fiancé is out of town this 
weekend and I'm going to dedicate an evening or two to stuff like this.


-w


begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
org:The Open Planning Project;OpenPlans
adr:;;1309 Ashwood Ave;Nashville;TN;37212;USA
email;internet:[EMAIL PROTECTED]
title:Lead Developer 
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
[EMAIL PROTECTED]
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: The big 3.0 ;)

[whit]

Alec Mitchell wrote:

On 4/3/07, Martin Aspeli <[EMAIL PROTECTED]> wrote:

Wichert Akkerman wrote:
>> - Wicked
>> - Needs to use createObject?type_name=Document — the way 
it is
>>   set up now, anything spidering the site with credentials 
will

>>   create objects, and any object clicked will create objects
>>   (this change will make it invoke portal_factory)
>
> Hasn't happened.

Am I right in thinking this should be considered a seriousish bug?


I don't see why this should be considered any better/worse than the
content add menu which uses the exact same links and will be shown on
all such pages as well.  From a spiders point of view, it's not
different, AFAIK.  Not that this isn't an important issue, but we've
lived with it for a long time.
who spiders with credentials? The real issue is clicky users creating 
content they don't actually edit.  This is more of an annoyance than a 
barn-burner considering it's a wiki convention that most of the time 
people use the syntax so they can rapidly create and populate a link.


this is like 3-4 line fix unless you wanted to create a proper add view 
(ie less effort than has been expended in writing emails about it).  
might have time this weekend to do it.


an kss inline of the add item page would be by far the best solution 
overall(still need above as a fallback). 


-w

--

-- d. whit morriss --
- senior engineer, opencore -
- http://www.openplans.org  -
- m: 415-710-8975   -

"If you don't know where you are,   
you don't know anything at all" 


Dr. Edgar Spencer, Ph.D., 1995

begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
org:The Open Planning Project;OpenPlans
adr:;;1309 Ashwood Ave;Nashville;TN;37212;USA
email;internet:[EMAIL PROTECTED]
title:Lead Developer 
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: The big 3.0 ;)

[whit]

Martin Aspeli wrote:

Raphael Ritz wrote:

Martin Aspeli schrieb:

[..]
There is a general developer mis-conception that Plone's not *too 
bad at* but sometimes we all do it: More options == better.



Could we maybe return to the issue that triggered this discussion,
namely whether or not to bann the smart folder settings from the
Plone control panel.


;)


In my view we should not do this because:

1. removing something that's been around for a while now
   just confuses people.

2. In the long run (aka when at some point moving to Zope 3
  entirely) there will be no ZMI anymore as we know it today.

3. Smart folders (aka Topics) are special in various ways and
   admittedly they are way more complex than the other regular
   content types. Simply saying that many people don't need their
   UI-configuration options may fall short here because I assume
   many sites don't make much use of topics (if at all).
   On those sites where they are used heavily I claim these options
   are desperatly needed.

On a related note: let's not forget that one of the strong points of
Zope/Plone has always been the possibility to do many things
TTW from a browser. In many real life situations, site admins don't
have file system access to the server deploying their site which defeats
in my view the current tendency to simply move everything to the
file system and then saying: "Oh, well, just provide your own view
class/whatever and override the default in your config.zcml."
For those site admins this is simply not an option.
(And note that I am not talking about TTW *development*,
I'm talking about *site configuration*.)


Maybe the bigger issue is that this control panel is very low level. I 
don't think it makes much sense to non-programmers, and compared to 
our other control panels, it's a lot less elegant and feels a lot less 
usable. Perhaps we can think of some more appropriate metaphors, and a 
better layout that make these settings more understandable for regular 
site admins?



absolutely. 

but alot things happen in async. if the proposition is "remove to zmi 
until ui treatment is available", I would have to return to our previous 
conversation tangent and start beating my drum again.  When we have 
knobs in limbo, what is our process?


-w


--

-- d. whit morriss --
- senior engineer, opencore -
- http://www.openplans.org  -
- m: 415-710-8975   -

"If you don't know where you are,   
you don't know anything at all" 


Dr. Edgar Spencer, Ph.D., 1995

begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
org:The Open Planning Project;OpenPlans
adr:;;1309 Ashwood Ave;Nashville;TN;37212;USA
email;internet:[EMAIL PROTECTED]
title:Lead Developer 
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: The big 3.0 ;)

[whit]

Martin Aspeli wrote:

whit wrote:

re: zmi. lets talk about being painfully modal. The fact we are 
having this conversation seems to indicate a different and wider 
issue to me.



Without wanting to get into an abstract and 
easy-to-talk-past-each-other discussion, I think you're right. :-)


A useful metric may be "if it's too complex for real users and thus 
not good to keep in the control panel, it should be configurable in 
code".


"Configurable in code" should not mean "go change config.py", it 
should mean "override this component or register something else for 
this interface" if you need to alter behaviour.


How's that for abstract and easy to misunderstand? :)


sort of? I only half agree if I understand you correctly.

we still have some larger knobs that can't be configured via the FS (or 
are more useful if not): persistent components being the big one I see 
here without thinking too hard.  I also think there is a level of 
complexity between average site admin control panel tasks and fullon fs 
configuration.


Also, our filesystem configuration story is sort of a mess too with all 
the different zope2 and zope3 "options" (ever tried to explain 
commenting out zcml or adding slugs to someone unfamiliar with zope3? 
does anyone doing core development now know Zconfig?)


this doesn't justify doing more TTW, it just makes "configurable in 
code" harder to sell as reasonable step downward from controlpanel.


As stated before, I think there is a place for some sort of extension of 
the plone.app.controlpanel and maybe making some reasonable linkage so 
if advanced options are available, we have a standard sane way of 
hooking them up and for the appropriate real users to get to them.  My 
prediction is that addon developers can and will do this(it's the path 
of least resistance)...


so we might as well have a good way to handle it.

-w

--

-- d. whit morriss --
- senior engineer, opencore -
- http://www.openplans.org  -
- m: 415-710-8975   -

"If you don't know where you are,   
you don't know anything at all" 


Dr. Edgar Spencer, Ph.D., 1995

begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
org:The Open Planning Project;OpenPlans
adr:;;1309 Ashwood Ave;Nashville;TN;37212;USA
email;internet:[EMAIL PROTECTED]
title:Lead Developer 
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

[Framework-Team] The big 3.0 ;)

[whit]

or maybe allowing an option that turns on advanced panels(or at least a 
way for addon developer create some sort of navigation to advanced 
options they may add).


re: zmi. lets talk about being painfully modal. The fact we are having 
this conversation seems to indicate a different and wider issue to me.


the argument that we are now using the zmi by design really rings hollow 
for me.  Though I strongly support generalizes ui that works with or 
without plone, I'm not sure designing in any more context switches into 
plone is at all a good idea.  Let's keep people in the application or on 
filesystem, not rummaging though our hot nineties legacy layer.


Context switching has almost always been an unfortunate bump on our 
learning curve for Plone. Just having to explain navigating the zmi 
increase our support burden.  People should design good configuration 
uis, not just stick badly drawn ones in the zmi.


There are options that make more sense in a plone setting even if not 
for the more general day to day site admin tweaks.  addon authors will 
add their own control panel regardless of what we say the right way is, 
so I would vote for giving them a more appropriate place to do this 
(with wicked, I see plenty of fertile options that I'm not at all 
interested in building zmi pages for but are definitely not basic 
configuration options).


we are also moving into a time where control panel style UIs make sense 
at any container level, not just the portal.


with these things in mind, we may need to rethink the application of the 
pattern we use in plone.app.controlpanels so it can be easily reused for 
things like advanced options or container level configuration.  This 
seems like the right direction, rather than claiming the inevitable use 
of better technology as wrong by decree and advocating a return to the 
bonny days of 1999.


long live frames!

-w


--

-- d. whit morriss --
- senior engineer, opencore -
- http://www.openplans.org  -
- m: 415-710-8975   -

"If you don't know where you are,
 you don't know anything at all" 



Dr. Edgar Spencer, Ph.D., 1995


___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: The big 3.0 ;)

[whit]

Martin Aspeli wrote:

whit wrote:

What's everyone else's excuse? :-)


explosive diarrhea.


Tiran once coded in the toilet at a sprint, so that won't do, Whit.


I didn't want to vomit on my keyboard.

-w

--

-- d. whit morriss --
- senior engineer, opencore -
- http://www.openplans.org  -
- m: 415-710-8975   -

"If you don't know where you are,   
you don't know anything at all" 


Dr. Edgar Spencer, Ph.D., 1995

begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
org:The Open Planning Project;OpenPlans
adr:;;1309 Ashwood Ave;Nashville;TN;37212;USA
email;internet:[EMAIL PROTECTED]
title:Lead Developer 
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: The big 3.0 ;)

[whit]

What's everyone else's excuse? :-)


explosive diarrhea.

-w

--

-- d. whit morriss --
- senior engineer, opencore -
- http://www.openplans.org  -
- m: 415-710-8975   -

"If you don't know where you are,   
you don't know anything at all" 


Dr. Edgar Spencer, Ph.D., 1995

begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
org:The Open Planning Project;OpenPlans
adr:;;1309 Ashwood Ave;Nashville;TN;37212;USA
email;internet:[EMAIL PROTECTED]
title:Lead Developer 
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: Fwd: [Framework-Team] Re: beta1 release timing

[whit]

my whining about documentation was more a selfish plea for more info in 
the channels I follow for something I don't know much about.
begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
org:The Open Planning Project;OpenPlans
adr:;;1309 Ashwood Ave;Nashville;TN;37212;USA
email;internet:[EMAIL PROTECTED]
title:Lead Developer 
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: beta1 release timing

[whit]

 - Consider some kind of compitability alias mechanism, so that when 
people keep using getToolByName(context, 'portal_types') we translate 
that to getUtility(ITypesTool), for as long as we need to (but still 
warning).
+1... I mean chrissakes.. getToolByName was supposed to be future 
proofing for this day...


Removing in 3.5 sounds completely unrealistic to me. If we find that 
by 4.0 most third party products that count (i.e. would be otherwise 
compatible) have been fixed, we can consider removal.


+100 and someone should blog or write a tutorial about these changes 
and how to utilize them.


-w


--

-- d. whit morriss --
- senior engineer, opencore -
- http://www.openplans.org  -
- m: 415-710-8975   -

"If you don't know where you are,   
you don't know anything at all" 


Dr. Edgar Spencer, Ph.D., 1995

begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
org:The Open Planning Project;OpenPlans
adr:;;1309 Ashwood Ave;Nashville;TN;37212;USA
email;internet:[EMAIL PROTECTED]
title:Lead Developer 
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: branching moment

[whit]

Alec Mitchell wrote:

I'm +1 for keeping 3.0 on trunk until the RC phase at least.  People
wanting to do feature development post-freeze can do so on branches.

sounds reasonable to me. speaking of, it's about time for the framework 
team to pass the torch isn't it?


-w

--

-- d. whit morriss --
- senior engineer, opencore -
- http://www.openplans.org  -
- m: 415-710-8975   -

"If you don't know where you are,   
you don't know anything at all" 


Dr. Edgar Spencer, Ph.D., 1995

begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
org:The Open Planning Project;OpenPlans
adr:;;1309 Ashwood Ave;Nashville;TN;37212;USA
email;internet:[EMAIL PROTECTED]
title:Lead Developer 
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

[Framework-Team] latest wicked

[whit]

http://cheeseshop.python.org/pypi?:action=display&name=wicked&version=1.1.1

fixed the on-save/registration issue limi observed

-w

--

-- d. whit morriss --
- senior engineer, opencore -
- http://www.openplans.org  -
- m: 415-710-8975   -

"If you don't know where you are,
 you don't know anything at all" 



Dr. Edgar Spencer, Ph.D., 1995

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

[Framework-Team] Re: ploneenv - Or how using workingenv for a common Zope2 project might look like ;-)

[whit]

Well, yes, but if one developer does edit buildout.cfg (we added a new 
requirement or a new step in the build process), everyone else svn up's 
that file and runs bin/buildout and their environments are the same 
again. The --requirements file is, as far as I understand, a one-off 
bootstrap.


the only difference between buildout.cfg and a -r file that I see is you 
can specify builds of non-python based products in a buildout.cfg. 
Either can live in an svn repo and be updated.


-r files can be combined with links pages and used as a sort of external 
way to manage distribution; requirements file let you specify what to 
install as a development egg(similar to buildout), why changing the 
links page will actually change what code is checked out as a 
development egg.


  In the case of building zope and plone, I don't think there is much 
advantage one way or another; most of the dependencies could be or 
should be eggs(and I think this should be the emphasis rather than 
forcing workingenv or buildout down anybodies throat).


If eggs work, you can use what you like; making a zc.buildout recipe to 
read requirements file would be pretty easy(see this script: 
https://svn.openplans.org/svn/PoachEggs/trunk/).


The situation changes case when looking at things like building a real 
Plone deployment setup: squid, pound, nginx, postfix for listen, etc. 
The little bit of work I've down with trying to split deployment and dev 
builds is that having the option to run just some of the build is really 
nice(either through options on a script or multiple scripts).  It also 
eliminates a bit of the fear factor that comes from installing a monolith.




-w


--

-- d. whit morriss --
- senior engineer, opencore -
- http://www.openplans.org  -
- m: 415-710-8975   -

"If you don't know where you are,
 you don't know anything at all" 



Dr. Edgar Spencer, Ph.D., 1995


___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: wicked - lxml dependency?

[whit]

Rocky wrote:

Hanno Schlichting wrote:
  

Is lxml a real dependency for the functionality we use in Plone or is it
optional or only required to run the tests?



If lxml is not required (but can be used) by wicked then the tests
should reflect the same thing imho.  The tests should conditionally
test lxml only if available.

If the tests fail because lxml doesn't exist, then wicked itself
shouldn't work when deployed either without lxml.

- Rocky


___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

  
they error, not fail(which is different). lxml is a tool for testing in 
this case.  the tests are old style unit tests and someday they will get 
rewritten in more modern forms.


the use lxml is primarily to make test output understandable by 
stripping out the whitespace created by TAL while testing the rendering 
of links (20 some tests, essentially AT/plone integration tests.  This 
suite is run twice, one to test basic setup, a second time to test the 
specialize plone registrations).  The dependency is on libxslt2-py or 
lxml.  wicked in no way uses lxml in it's actua function.


we could turn these tests off for systems without libxslt or lxml and 
emit a warning. if someone has a whitespace normalizing routine that is 
standard library friendly that would work too.


-w

--

-- d. whit morriss --
- senior engineer, opencore -
- http://www.openplans.org  -
- m: 415-710-8975   -

"If you don't know where you are,   
you don't know anything at all" 


Dr. Edgar Spencer, Ph.D., 1995

begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
org:The Open Planning Project;OpenPlans
adr:;;1309 Ashwood Ave;Nashville;TN;37212;USA
email;internet:[EMAIL PROTECTED]
title:Lead Developer 
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] wicked - lxml dependency?

[whit]

Hanno Schlichting wrote:

Heya.

I noticed that a lot of tests in wicked fail on my machine, as I don't
have lxml installed.

Is lxml a real dependency for the functionality we use in Plone or is it
optional or only required to run the tests?

Hanno

P.S. I tried to install lxml via easy_install and while it claims to
install fine, I get Bus errors during test runs of wicked then :(


___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

  
it's used in the tests (to strip whitespace). iirc, any working version 
of libxml2 should work(both for the test and lxml, though lxml needs to 
be rather current).  lxml or libxml is not needed for any of wicked's 
functionality.



-w

--

-- d. whit morriss --
- senior engineer, opencore -
- http://www.openplans.org  -
- m: 415-710-8975   -

"If you don't know where you are,   
you don't know anything at all" 


Dr. Edgar Spencer, Ph.D., 1995

begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
org:The Open Planning Project;OpenPlans
adr:;;1309 Ashwood Ave;Nashville;TN;37212;USA
email;internet:[EMAIL PROTECTED]
title:Lead Developer 
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] ploneenv - Or how using workingenv for a common Zope2 project might look like ;-)

[whit]

chris finally released buildit(see planet.plone.org) and a bunch of 
recipes for building various stuff.


for either approach, buildit is a pretty useful tool and not 
particularily concerned with eggs therefore is largely orthogonal to the 
workingenv/buildout issues.


-w
begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
org:The Open Planning Project;OpenPlans
adr:;;1309 Ashwood Ave;Nashville;TN;37212;USA
email;internet:[EMAIL PROTECTED]
title:Lead Developer 
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Cleaning up the bundles a bit, getting rid of getCVS.sh

[whit]

+1(as a developer)

no word from dr. mauerer.

-w

Alexander Limi wrote:

Hi,

Currently, we have two dependencies that should be handled in a better 
way than they are now: AdvancedQuery and ZopeVersionControl.


I propose that we check these in to a directory for third-party 
components, the same way as Kapil did it when he had ZVC located in 
the ObjectRealms SVN. Something like this:


svn.plone.org/plone/thirdparty/AdvancedQuery/tags/2.2
svn.plone.org/plone/thirdparty/ZopeVersionControl/tags/0.3.2

(I'm offline right now, and can't remember if we have a suitable 
third-party directory or not — but you get the idea :)


...and then link these in as svn:externals. It's annoying (and 
error-prone, plus it doesn't work on Windows) to have to invoke a 
shell script to get these — as well as the fact that both of these 
products have been stable for a long long time. We can switch it back 
if/when they ever end up in a public SVN repository.


--Alexander Limi · http://limi.net


___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team




--

-- d. whit morriss --
- senior engineer, opencore -
- http://www.openplans.org  -
- m: 415-710-8975   -

"If you don't know where you are,   
you don't know anything at all" 


Dr. Edgar Spencer, Ph.D., 1995

begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
org:The Open Planning Project;OpenPlans
adr:;;1309 Ashwood Ave;Nashville;TN;37212;USA
email;internet:[EMAIL PROTECTED]
title:Lead Developer 
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Plip : indexing files

[whit]

At this time there are 2 new things to consider :

- portal transforms may overload the zope server

- there may be decorators that should be applied to files in order to
handle properly specific extra fields (especially for multimedia files :
metadata etc.)

* Concerning overload of zope server : I think that we should have an
asynchronous portal transform that may run as a separate twisted deamon.
This may live together with portal_transforms and may be called
asynchronous_portal_transform (APT). The only difference with
portal_transforms is that we need to give a callback method to APT in
order to allow it to send the result of the transform after a while.
Therefore if a content type is APT-aware and APT is activated, APT is used
instead of portal_transforms. This allow to move the overload to one or
many dedicated servers for example. We may also take a look at BlueDCS (I
just heard of it but never tried it)
  
wicked.fieldevent allows you to register subscribers for fieldstorage 
events.  These subscribers could be asyncronous(maybe just some 
instructions that clockserver could handle later).   I would try this first.


-w

--

-- d. whit morriss --
- senior engineer, opencore -
- http://www.openplans.org  -
- m: 415-710-8975   -

"If you don't know where you are,   
you don't know anything at all" 


Dr. Edgar Spencer, Ph.D., 1995

begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
org:The Open Planning Project;OpenPlans
adr:;;1309 Ashwood Ave;Nashville;TN;37212;USA
email;internet:[EMAIL PROTECTED]
title:Lead Developer 
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: wicked merged

[whit]

Martin Aspeli wrote:

Alexander Limi wrote:

What's the story behind the AdvancedQuery dependency? (Or did I  
misunderstand?)


Wicked depends on AQ, and though whit forgot to update the scripts to 
pull it down, it's there now so you should get it.


Martin
sorry about that one.forgot to add it till martin let me know it was 
missing.


aq is a dependency mainly to avoid multiple catalog calls. now that 
dieter is a zope foundation contributer I'm going to email him and see 
if he'd be interested in adding it zope2 proper.



-w

--

-- d. whit morriss --
- senior engineer, opencore -
- http://www.openplans.org  -
- m: 415-710-8975   -

"If you don't know where you are,   
you don't know anything at all" 


Dr. Edgar Spencer, Ph.D., 1995

begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
org:The Open Planning Project;OpenPlans
adr:;;1309 Ashwood Ave;Nashville;TN;37212;USA
email;internet:[EMAIL PROTECTED]
title:Lead Developer 
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

[Framework-Team] wicked merged

[whit]

r12050-12057

http://dev.plone.org/plone/changeset/12050/ 
http://dev.plone.org/plone/changeset/12057/


checking out the bundles should work fine unless I've forgotten to check 
something. drop me a line if I've forgotten anything.


-w

--

-- d. whit morriss --
- senior engineer, opencore -
- http://www.openplans.org  -
- m: 415-710-8975   -

"If you don't know where you are,
 you don't know anything at all" 



Dr. Edgar Spencer, Ph.D., 1995


___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: five.intid and object_implements index in Plone 3

[whit]

Rob Miller wrote:

Alec Mitchell wrote:

<--SNIP all the discussion about five.intid-->


Instead, why not make a simple addon product (with a simple GS
profile) that installs these dependencies and the necessary utils and
indexes, and attach it to a PLIP for 3.5?  Having intids would be
great, but it would be better if it came along with a real zope 3-ish
reference solution, not more portal_catalog bloat for convenience, and
there's certainly no time for that now but it's probably a great thing
to hack on in Sorrento.  :-)


i pretty much agree w/ this, although i do think that adding an
object_implements index to the catalog (i thought it was there 
already?) is A

Good Idea, and is low enough impact to be reasonable to do now.


and doesn't in anyway require five.intid which is the risky part.

-w

begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
org:The Open Planning Project;OpenPlans
adr:;;1309 Ashwood Ave;Nashville;TN;37212;USA
email;internet:[EMAIL PROTECTED]
title:Lead Developer 
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

[Framework-Team] Re: five.intid and object_implements index in Plone 3

[whit]

Martin Aspeli wrote:

Hi Whit,

On 1/10/07, whit <[EMAIL PROTECTED]> wrote:

Martin Aspeli wrote:
> Hi guys,
>
> I'm toying with the idea of introducing five.intid as a dependency for
> Plone 3. Whit is responsible for this creation, so I'd like this input
> as well, but from discussions with him it seems quite useful.
>
> - It can be combined with Zope 3's catalog implementation
> - It can act as a generic reference catalog
s/reference catalog/uid catalog/

it is a catalog of references(keyreference object to be exact), but to
create an content object -> content object reference system ala AT
reference lite, we would need to whip up a bit more(though not too 
much).


Oh, yes, true. Well, a content object could potentially store a list
of int ids its referencing, could it it not?

Are int ids stable when objects move? Are modified?

What about export/import?
they should be stable for both iirc. (if not, events should be able to 
maintain this)



> - We (I) could simpilfy plone.app.redirector a little bit by using it
> instead of a custom path storage (well, the storage would still need
> to be there to remember where things used to be, but it would be a bit
> more standards-based)
my brain is tickled but I can't remember why


:-)

Just because I stole your code and concepts doesn't mean I can't take
all the credit. ;)

/me laughs.

you deserve the credit ;)

I should remember the code better. I'm just glad someone salvaged it...



> - We could use intids in more generic places like that fabled
> selection widget. That is, we don't have to rely on context.UID().
>
this is a biggee.  In wicked, which hopefully soon will do all of it's
"relational" behavior internally, I've moved to only accessing uid via
an interface(IUID, a string or integer).  This opens up the ability to
say, make wicked links to AT content and listen content(done w/ plone
schemas).


Yeah, that's my biggest win as well. Plus, it standarises us on what
Zope 3 is using (more or less).


> - Add a subscriber for Products.CMFCore.IContentish, so that it takes
> care of all content
+1 to using IContentish, or maybe even constraining the interface more.
I discovered a ton of headaches as tried binding the subscriber from
IPersistent on inwards;  Plone and CMF do alot of ugly things with
persistence in site creation; intid is based on an object having an oid
and is subscribed to object create, therefore depends on fairly normal
ZODB behavior or you get ugly lowlevel errors.


Right. I would've thought IContentish was safe, but we obviously need 
to test.



> - Does it work well with portal_factory?
seems to work ok... I would like to see more investigation.


Cool. portal_factory basically clones objects in funny ways, so ids
may change between the in-factory and out-of-factory objects. Still,
that ought to be ok.

what do we currently depend on portal_factory for? any possibility we 
could move to a fate style addforms by 3.5?(different topic)

> - Does it give any noticable overhead (looks OK to me)?
as long as the subscriber are reasonably constrained.


My thought too.


> - Is it using Zope 2.10 or Zope 2.9's local component registrations
> (should be easy to fix up anyway)?
I wrote it against 2.9 so it's probably using that utility reg routine.


Believe so. Anyway, doing it in 2.10 is easier :)


my main concern is getting five.intid hammered on and probably at this
early stage, not piling too many irreversible dependencies upon it.

my reasoning: Much of what is scary to me about this code adapting intid
to zope2 is what made it so nice for mfaasen writing it in zope3.  It
works at what ends up in Plone being a very low level and during
development, when things broke, you couldn't even create a plone
site(plone site creation alerted my to a myriad of possible issues with
keyreferences and the myriad of things you can do with a
transaction).This got fire tested because during it's development I
was working with multiple other developers who just wanted to work on
site ui(was a real headache on a couple of occasions).

I had to work very hard to get keyreferences and acquisition to play
nice.   Due to the tight relationship with the persistence mechanism,
when things do go wrong, you are often looking at errors upon
transaction commit rather than in the code that is causing the error.

so that is my caveat emptor.  wiggy informed me that the cheeseshop link
for five.intid is broken. I'll try to fix this up, but otherwhise, just
do an svn pull for most current version.


So how tested/stable would you say it is? Did you hammer it in the
real world, or do you think there are problems you don't know how to
resolve or areas which are largely untested?

real world == real world development situations but not run in 
production(tagger is waiting for som

Re: [Framework-Team] Re: five.intid and object_implements index in Plone 3

[whit]

Martin Aspeli wrote:

>  - Add the intid from five.intid as an index and metadata. This allows
> cross-referencing between the two.

This seems valuable.  It already bridges the annoying gap where we don't
currently add UID to the standard catalog as an index or metadata.


We could possibly add a similar bridge in uid_catalog to make the
circle complete. I'd be happy if we moevd away from AT UIDs and
towards five.intid UIDs across the board, though.

iirc, intid is fairly pluggable. for  instance, if you still wanted to 
use at style intids, you could just override the generation method in 
the utility class and register your new class instead(though that would 
make you unable to use the IBtrees that z3 index employ, iirc). 

the integer id is more efficient for indexes(dig into the zcatalog and 
you will find everything run off of integers).


before jensens bangs a drum about his UUids, I think we should make the 
distinction between intid(really good for internal use) and other sorts 
of UIDs that may be important for other kind of operations(global 
merges, migration, etc).


-w
begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
org:The Open Planning Project;OpenPlans
adr:;;1309 Ashwood Ave;Nashville;TN;37212;USA
email;internet:[EMAIL PROTECTED]
title:Lead Developer 
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

[Framework-Team] Re: five.intid and object_implements index in Plone 3

[whit]

Martin Aspeli wrote:

Hi guys,

I'm toying with the idea of introducing five.intid as a dependency for
Plone 3. Whit is responsible for this creation, so I'd like this input
as well, but from discussions with him it seems quite useful.

- It can be combined with Zope 3's catalog implementation
- It can act as a generic reference catalog

s/reference catalog/uid catalog/

it is a catalog of references(keyreference object to be exact), but to 
create an content object -> content object reference system ala AT 
reference lite, we would need to whip up a bit more(though not too much).

- We (I) could simpilfy plone.app.redirector a little bit by using it
instead of a custom path storage (well, the storage would still need
to be there to remember where things used to be, but it would be a bit
more standards-based)

my brain is tickled but I can't remember why

- We could use intids in more generic places like that fabled
selection widget. That is, we don't have to rely on context.UID().

this is a biggee.  In wicked, which hopefully soon will do all of it's 
"relational" behavior internally, I've moved to only accessing uid via 
an interface(IUID, a string or integer).  This opens up the ability to 
say, make wicked links to AT content and listen content(done w/ plone 
schemas).

If you want to see it in action, the doctest is very descriptive and
easy to follow:
http://svn.plone.org/svn/collective/five.intid/trunk/five/intid/README.txt 



I think setting it up would be quite easy:

- Add to the bundle
- Add a subscriber for Products.CMFCore.IContentish, so that it takes
care of all content
+1 to using IContentish, or maybe even constraining the interface more.  
I discovered a ton of headaches as tried binding the subscriber from 
IPersistent on inwards;  Plone and CMF do alot of ugly things with 
persistence in site creation; intid is based on an object having an oid 
and is subscribed to object create, therefore depends on fairly normal 
ZODB behavior or you get ugly lowlevel errors.

- Add a migration step to add the utility
- Possibly add a step to index existing content (could be optional)
- Add it to the components.xml setup

Outstanding questions:

- Does it work well with portal_factory?

seems to work ok... I would like to see more investigation.

- Does it give any noticable overhead (looks OK to me)?

as long as the subscriber are reasonably constrained.


- Is it using Zope 2.10 or Zope 2.9's local component registrations
(should be easy to fix up anyway)?

I wrote it against 2.9 so it's probably using that utility reg routine.


I then think we should consider getting the catalog to do two things:

- Add an object_implements index. I know the one that does any
"adaptable-to" interface from membrane is a bit slow, but one that
just indexes the names of zope.interface.providedBy(obj).flattened()
should be quick.


+1

- Add the intid from five.intid as an index and metadata. This allows
cross-referencing between the two.


+1

I'd rather we get this in now so people can start depending on it,
than see lots of half-baked unique-object-reference-and-lookup
implementations (e.g. plone.app.redirector is very dependent on the
path of an object at the moment, since it can't assume the UID catalog
is reliable for all content). 

ah! now I remember ;)

It looks to me like it'd be fairly low
risk, the only iffy thing being reindexing existing content on
migration if necessary.

my main concern is getting five.intid hammered on and probably at this 
early stage, not piling too many irreversible dependencies upon it. 

my reasoning: Much of what is scary to me about this code adapting intid 
to zope2 is what made it so nice for mfaasen writing it in zope3.  It 
works at what ends up in Plone being a very low level and during 
development, when things broke, you couldn't even create a plone 
site(plone site creation alerted my to a myriad of possible issues with 
keyreferences and the myriad of things you can do with a 
transaction).This got fire tested because during it's development I 
was working with multiple other developers who just wanted to work on 
site ui(was a real headache on a couple of occasions).


I had to work very hard to get keyreferences and acquisition to play 
nice.   Due to the tight relationship with the persistence mechanism, 
when things do go wrong, you are often looking at errors upon 
transaction commit rather than in the code that is causing the error. 

so that is my caveat emptor.  wiggy informed me that the cheeseshop link 
for five.intid is broken. I'll try to fix this up, but otherwhise, just 
do an svn pull for most current version.


-w

begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
org:The Open Planning Project;OpenPlans
adr:;;1309 Ashwood Ave;Nashville;TN;37212;USA
email;internet:[EMAIL PROTECTED]
title:Lead

Re: [Framework-Team] Re: wicked integration w/ plone 3

[whit]

Martin Aspeli wrote:

On 1/8/07, whit <[EMAIL PROTECTED]> wrote:


[ ]  enable wiki
[ ]  use media wiki syntax
<- enabled types ->
   Event
   Page
   News


Why do we need both an "enable wiki" option and a list of enabled
types? If all the types are deselected, wiki syntax is off by
definition, no?

yeah, I just did it to be explicit and so everything could be turned off 
in one click. should I pare it down to types and the media wiki toggle?


-w
begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
org:The Open Planning Project;OpenPlans
adr:;;1309 Ashwood Ave;Nashville;TN;37212;USA
email;internet:[EMAIL PROTECTED]
title:Lead Developer 
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: wicked integration w/ plone 3

[whit]

the old stuff has been reviewed but the new stuff should be looked over 
too. 

banging on the controlpanel right now(wrote the code, still need to 
test).The rough and ready choices are the following::


[ ]  enable wiki
[ ]  use media wiki syntax
<- enabled types ->
  Event
  Page
  News

-w


Alexander Limi wrote:

On Sun, 07 Jan 2007 20:23:13 -0800, whit <[EMAIL PROTECTED]> wrote:

alright, I shuffled around the registrations so Document, Event, and 
NewItem can be registered individually.  I scratched the entry point 
stuff since we really don't have an egg story yet(and entry points 
are invisible if a distribution isn't actually installed in some 
fashion...oh well, maybe next time)


All the tests for wicked and plone are passing.  have got about 
45mins now to try to kick out a basic interface for the controlpanel.


the merge is going to be basically 1 line of zcml, including the py 
code in wicked and whatever I get done with the controlpanel.  Do you 
want me to cut a bundle/branch for this, or just commit to trunk with 
the zcml commented out?


I don't think a branch as such is required, but whatever is going to 
ship with Plone should be reviewed by a member of the FW team. I can't 
remember if anybody reviewed Wicked yet? :)


--Alexander Limi · http://limi.net


___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team



begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
org:The Open Planning Project;OpenPlans
adr:;;1309 Ashwood Ave;Nashville;TN;37212;USA
email;internet:[EMAIL PROTECTED]
title:Lead Developer 
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

[Framework-Team] Re: wicked integration w/ plone 3

[whit]

I should ammend previous email to say... I see a couple broken tests in 
plone, but they don't appear to have anything to do with wicked on the 
surface.


-w


___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

[Framework-Team] Re: wicked integration w/ plone 3

[whit]

alright, I shuffled around the registrations so Document, Event, and 
NewItem can be registered individually.  I scratched the entry point 
stuff since we really don't have an egg story yet(and entry points are 
invisible if a distribution isn't actually installed in some 
fashion...oh well, maybe next time)


All the tests for wicked and plone are passing.  have got about 45mins 
now to try to kick out a basic interface for the controlpanel.


the merge is going to be basically 1 line of zcml, including the py code 
in wicked and whatever I get done with the controlpanel.  Do you want me 
to cut a bundle/branch for this, or just commit to trunk with the zcml 
commented out?


-w



___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: wicked integration w/ plone 3

[whit]

Hanno Schlichting wrote:

Martin Aspeli wrote:
  

whit wrote:



does anyone have a good formlib example for a controlpanel that
*doesn't* edit a cmf tool?
  

plone.app.controlpanel has none? There are examples of formlib in
plone.app.contentrules and plone.app.portlets.portlets, and Rocky has a
formlib tutorial. Otherwise, Hanno may have light to shed. :)



The approach I have taken in plone.app.controlpanel is to introduce a
middleware-adapter for the IPloneSiteRoot that will act as the context
for the formlib form. Read the full story in
http://dev.plone.org/plone/browser/plone.app.controlpanel/trunk/README.txt

This approach allows you to do any kind of work in the adapter. If you
look at the types control panel you won't see any CMF tools usage inside
there ;)

Hanno
  

nice! that should work great!

-w
begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
org:The Open Planning Project;OpenPlans
adr:;;1309 Ashwood Ave;Nashville;TN;37212;USA
email;internet:[EMAIL PROTECTED]
title:Lead Developer 
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

[Framework-Team] Re: wicked integration w/ plone 3

[whit]

Alexander Limi wrote:



On Fri, 05 Jan 2007 10:57:34 -0800, whit 
<[EMAIL PROTECTED]> wrote:



Raphael Ritz wrote:

What I would like to see in addition
(but I admit that it's too late to asked for that now) is a way
to offer the (power) user to specify the content type to be created
on add. Something like (in the context of a page):

 ... as outlined in the [[Plone UI Sprint Announcement]][News Item]
 our next meeting will be focusing on UI (more details on the
 [[Plone UI Sprint]][Event] calendar entry)
 ...

would then generate a 'News Item' and an 'Event' entry respectively.

I guess mediawiki doesn't really have a concept of "content types".  the
syntax extension we've been talking about at openplans is similar, but
has a more open ended application.  It might work sort of like this:

((Link text || content-type ))  #
just create a content type


I'm reluctant to add too much syntax beyond basic linking.
understandably.  I think in situations people will really want this(like 
at topp), but that doesn't mean it makes sense to ship with it or focus 
on it.  see comments at bottom.


What I'd prefer in the content type use case is that the link to 
create a new page goes to folder_factories (which I will fix for Plone 
3.0, I promise ;) and some Ajax pulldown variant for those with JS — 
which allows you to select which type you want.


+100 to that. been longing for this for a while ;)
If (for instance) Page is the only allowed content type in the 
location you're in, this intermediate step will not be there, obviously.


In general, the UI that indicates that you can create a new page needs 
some love. :)


in general,  I think concepts like syntax extension are probably best 
handled by thirdparty libs(or shippable as options to be activated via 
zcml).   this way, it's easy to warn people of the potential effects on 
performance or usability...no pointy clicky road to hell. 

This is sort of where setuptools dovetails very nicely with zope3; it's 
easy to generate vocabularies based on entry points that handle the 
component registration code. Folks can extend your ui with no bad 
touching, CMFQi madness, or commit rights.  I'm very happy about how 
easy this is to extend without invasion and how easy it is to add 
options rather than shoving features down peoples throats. 

well it looks like it'll be pretty easy... still have to finish writing 
it ;) 


-w
begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
org:The Open Planning Project;OpenPlans
adr:;;1309 Ashwood Ave;Nashville;TN;37212;USA
email;internet:[EMAIL PROTECTED]
title:Lead Developer 
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: wicked integration w/ plone 3

[whit]

Alexander Limi wrote:
On Fri, 05 Jan 2007 02:33:54 -0800, Martin Aspeli <[EMAIL PROTECTED]> 
wrote:



I don't think having TTW configuration for which *fields* should get
the Wicked treatment makes much sense (too low level). Having a way to
turn the behaviour on/off and possibly change the syntax choice makes
sense.


Usually, per-content-type settings is the best combination of 
flexibility and combinatorial explosions. ;)
are those the good kind or bad kind? per content type is probably pretty 
easy, I since I'm guessing each ATCT content type has a uniqueish iface.



But then what happens with documents using the "old" syntax? Maybe it
can be a multi-select rather than single select, so you get:

Wicked syntax:

 [x] Wicked style ((words))
 [ ] MediaWiki style [[words]]

And if you untick both, you get no wicked at all?


I wouldn't even offer this. The likelihood of a document having [[]] 
or (()) without being a wiki page is extremely unlikely. This level of 
control makes no sense in the user interface, it should be reduced to 
a simple:


[ ] Support wiki-style linking

…in the content type panel. If the ability to disable selectively the 
[[]] or (()) syntax should be there, it should be in the configuration 
of the product. It's very unlikely that you want one content type to 
support one syntax, one the other, but none of them both different ones.



(it's not a product anymore ;)

anyway, let make sure I have this right.  Do we want to allow people to 
choose both [[]] and (()) globally? or just one or the other? both seems 
silly to me, but that's just my gut.


it's worth remembering that a formlib control panel like this could 
offer the options at a folder level ie the site uses (()) but individual 
folder use [[]].  We don't have "folder controlpanel ui" but it does 
seem useful in scenarios like this.


a gestalt of marten and my suggestion is sort of the quickest way to 
having a control panel if not the most optimal. enabling by content type 
is a bit more work(not super complicated but basically a registration 
class for each content type). Maybe I'll do the one for document as a start.



In any case, I say we enable by default for documents and people can
turn on for other things if need be.


I think it should be on for everything we ship that has a Rich Text 
field. Then you can disable it if you want. Wikis are becoming 
commonplace enough for people to expect that syntax to work, and it's 
unlikely to have false positives unless you are doing something very 
very specific.


interesting. turning on all textfields is easily done but I'll have to 
think a bit on how to blacklist fields and content types(the approach 
above sort of takes care of this, though I'm starting to see a need for 
schema unique interfaces for the actual field ala IDescription / 
IPrimaryField).  

Also worth considering, description is frequently a TextField and 
frequently rendered from catalog metadata.   is that an acceptable 
incongruity? this could change when wicked's cacheing moves to being 
utility driven rather than annotation(and cache access no longer depends 
on having the context in hand).
One of the cases I could think of would be programming, things like 
setMethod(( blah )). Does wicked parse inside  and  tags?


currently it is not very lisp friendly.  creating some mechanism for 
ignoring certain blocks would indeed be valuable, possible by creating a 
small pipeline(filter for wickedable chunks, wicked filter them, put it 
back together, render whole kabob).   getting into xslt territory here, 
maybe there is stuff in deliverance that could help keep this fast.


-w

begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
org:The Open Planning Project;OpenPlans
adr:;;1309 Ashwood Ave;Nashville;TN;37212;USA
email;internet:[EMAIL PROTECTED]
title:Lead Developer 
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: wicked integration w/ plone 3

[whit]

Interesting idea. The problem is possibly that people may not know the
full name of the content type (this is a vocabulary thing rather than
a free text thing), but certainly supporting this optionally would be
cool. I'd assume it wouldn't even be that hard to add (possibly at a
later stage).

yeah, wikiwyg is one approach to this(richtext editor that spew wiki 
syntax).  I think rapheal summed it up when he said power user; you 
would assume other users would probably pick this up via cut and paste.


anyway, it's pretty extensible, but for plone itself, we should probably 
keep it super simple.  (()) and [[]] are pretty readable, but I would 
like to emphasize any other syntax extension to be optional both to make 
optimal performance(since wicked does occasionally violate lurker's 
provision against caculation on rendering ;) ) easy to maintain and keep 
the user experience clean by default.


fortunately, persistent components make this much easier!

-w
begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
org:The Open Planning Project;OpenPlans
adr:;;1309 Ashwood Ave;Nashville;TN;37212;USA
email;internet:[EMAIL PROTECTED]
title:Lead Developer 
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: wicked integration w/ plone 3

[whit]

Raphael Ritz wrote:

Martin Aspeli schrieb:

[..]


I don't think having TTW configuration for which *fields* should get
the Wicked treatment makes much sense (too low level). 


Agreed.

But in the long run it might very well make sense.

I like for instance the 'textfilter' approach and I could
imagine more functionality managed that way. I think in particular
of the way in which I currently support inline citations in CMFBib
via PortalTransforms which sucks in that it's not really a
trafo between different mime types but only fake ones.
Similar for 'safe-html' or 'html-captioned'.
Having these testfilter-based would be much nicer I think.
yay! death to txtfilter, long live txtfilter.  I thought I was the only 
one who cared.


this is pretty much the idea behind wicked.fieldevent[1].  txtfilter is 
actually re-implemented as an example in wicked.fieldevent but it was 
more efficient to register wicked directly as a subscriber to render 
rather than put it into a txtfilter pipeline. If you're filters are 
orthogonal(ie don't require sequential dispatch), registering them 
directly as fieldevents will work quite nicely.  since we can do 
persistent components now, registering and unregistering the behavior 
should be super easy(mainly an interface management problem)



_1: 
http://svn.plone.org/svn/collective/wicked/lib/wicked/trunk/wicked/fieldevent/


Having the possibility to configure TTW (ZMI or configlet)
which filters to apply for which fields - maybe even controled
by conditions (e.g., safe-html filtering is skipped for content
coming from trusted users to make up an example) could go a long
way.

[..]



Wicked types:

[ ] News Item
[ ] Event
[x] Document



Talking about content types: What I would like to see in addition
(but I admit that it's too late to asked for that now) is a way
to offer the (power) user to specify the content type to be created
on add. Something like (in the context of a page):

 ... as outlined in the [[Plone UI Sprint Announcement]][News Item]
 our next meeting will be focusing on UI (more details on the
 [[Plone UI Sprint]][Event] calendar entry)
 ...

would then generate a 'News Item' and an 'Event' entry respectively.

Browsing through the code, I see that 'add_content' actually
supports this but I was unable to find this in the UI.
I guess mediawiki doesn't really have a concept of "content types".  the 
syntax extension we've been talking about at openplans is similar, but 
has a more open ended application.  It might work sort of like this:


((Link Text | Resulting Document Title or existing Document))   # 
link different than title or id


((New Link Text | Old Link Text))   # 
change link text


((Link text | http://externallink.com)) # 
not really needed with intelligenttext


((Link Text | ../path/to/target ))  # 
link to a specific item, document creation or searching scope


((Link text | target specification | content-type ))# 
above + contentype


((Link text || content-type ))  # 
just create a content type


the text filter pattern is easier to code if you have a bounded area 
(though my regex foo is not enormous).  for simplicity, I would prefer 
to build the syntax within the (()), but what happens there(in txtfilter 
speak, "the chunk") could be taken as far as anyone wants to.  

The best junction for this to take place is the actual fieldevent  
subscriber, after wicked is initialize but before the output is 
rendered.   The filter object gives access to the parsed chunks and 
provides a handle to the cache;   simple preprocess the chunks and stick 
the results in the cache. 

basically this is what happens on the storage of a wicked field minus 
rendering(the query algorithm on storage also are a bit more optimized 
so the pattern might speed things up a bit though most of the time, 
things are simply pulled from the cache).


as you pointed out, some of the infrastructure is already there. Most of 
the rest is pretty fun/easy programming and put the new components 
together as a base configuration option that can be chosen from the 
control panel.




Anyway: +1 on the merge

Raphael

PS: could be just me but when trying to play with the review
bundle it just didn't work (complaining about a missing migration).
Also, when trying to follow the 'easy_install' suggestion that
I found somewhere I only get:

"""
Creating /extra2/sites/testWicked/lib/python/site.py
Searching for wicked
Reading http://www.python.org/pypi/wicked/
Couldn't find index page for 'wicked' (maybe misspelled?)
Scanning index of all packages (this may take a while)
Reading http://www.python.org/pypi/
No local packages or download links found for wicked
error: Could not find suitable distribution for 
Requirement.parse('wicked')

[EMAIL PROTECTED] testWicked]$
"""

No time to look deeper into this at the moment :-(

I need to make a

Re: [Framework-Team] wicked integration w/ plone 3

[whit]

Martin Aspeli wrote:

Whit,

You rock. :)


thanks! :)

Will skim through the code today, but I'm very optimistic that we
should merge during the weekend.

I don't think having TTW configuration for which *fields* should get
the Wicked treatment makes much sense (too low level). 
TTW would be really hard at this point since schemas are not really 
persistent objects. as neat as it would be, I don't think this will 
really be possible until we get to persistent z3 schemas.

Having a way to
turn the behaviour on/off and possibly change the syntax choice makes
sense.


that's what I'm angling towards.


But then what happens with documents using the "old" syntax? Maybe it
can be a multi-select rather than single select, so you get:

Wicked syntax:

[x] Wicked style ((words))
[ ] MediaWiki style [[words]]

And if you untick both, you get no wicked at all?

My thinking is similar, but with radio buttons: off, (()), [[]] .  If we 
want to support [[]] and (()) at the same time, I would add another 
choice(basically another regex).  At an infrastructure level, I thought 
about making multi regexes possible as solutions, but it was simpler not 
too and still easy to give the option.  

At a higher level multiple regexes could create a usability issue of 
having multiple syntax globally(more things for a user to remember).   
By making free for all linking an explicit choice, site admin might 
think more about it(or at least it's easier to describe why you wouldn't 
actually want to do this in the interface).


"off" gives you no wicked.  at some point, we might want to offer 
"freeze" (no new parsing of wicked links), and a way to turn wicked off 
and make the links permanent.  Until then, there will be the potential 
for inactive wicked (([[rubbish]]))  littering documents after it's been 
turned off.



In any case, I say we enable by default for documents and people can
turn on for other things if need be. A slightly more ambitious
configuration solution would be that you have some vocabulary
(probably a utility vocabulary with a small utility for each possible
content type) that marks which content types can support wiki syntax
(the exact fields to use may be properties of the utility or set in
ZCML somewhere), and then you get another multi-select:

Wicked types:

[ ] News Item
[ ] Event
[x] Document
this will probably require some modification to ATCT (I chose not to do 
that this time) or at least some new registration schemes(instead of 
registering the content interface to IAmWicked, it would go straight to 
IATCTNewsItem).  entry points look like a nice and easy way to build the 
vocabularies and handling the registering and unregistering since they 
are orthogonal to zcml and 3rd party folks can easily add their custom 
content to the interface.  

does anyone have a good formlib example for a controlpanel that 
*doesn't* edit a cmf tool?


If for 3.0 we only get it on documents (but third parties can mark
whatever fields in their own ZCML) I don't think that's a great loss,
though.


cool!

-w


On 1/5/07, whit <[EMAIL PROTECTED]> wrote:

initially seems to be working using ATDocument unaltered(no special
fields, no special content).

I need to do a bit more testing, but wicked's tests run against ATCT
without issue(in 3 flavors: wicked for all AT text fields, just primary
textfield for newsitem, event and document and document only).

see:
http://svn.plone.org/svn/collective/wicked/lib/wicked/trunk/wicked/plone/ 



what fields get the wicked treatment is current determined in zcml(the
zcml marks the specific fields to enact behavior therefore has to happen
act configuration time rather than via persistent component).

This provides some flexibility, but later we may want to mark the fields
more explicitly(say, in the content class itself).   I chose the 3
configuration options above mainly to cess out possible problems; I
imagine we would decide on a configuration to ship plone with, and then
the intrepid could twiddle the zcml if they so desired.

Probably document-only.zcml would be the best default.

that leaves the controlpanel...which is about a third done...

night,

-w





___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team








begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
org:The Open Planning Project;OpenPlans
adr:;;1309 Ashwood Ave;Nashville;TN;37212;USA
email;internet:[EMAIL PROTECTED]
title:Lead Developer 
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

[Framework-Team] wicked integration w/ plone 3

[whit]

initially seems to be working using ATDocument unaltered(no special 
fields, no special content). 

I need to do a bit more testing, but wicked's tests run against ATCT 
without issue(in 3 flavors: wicked for all AT text fields, just primary 
textfield for newsitem, event and document and document only). 

see: 
http://svn.plone.org/svn/collective/wicked/lib/wicked/trunk/wicked/plone/


what fields get the wicked treatment is current determined in zcml(the 
zcml marks the specific fields to enact behavior therefore has to happen 
act configuration time rather than via persistent component). 

This provides some flexibility, but later we may want to mark the fields 
more explicitly(say, in the content class itself).   I chose the 3 
configuration options above mainly to cess out possible problems; I 
imagine we would decide on a configuration to ship plone with, and then 
the intrepid could twiddle the zcml if they so desired. 


Probably document-only.zcml would be the best default.

that leaves the controlpanel...which is about a third done...

night,

-w



begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
org:The Open Planning Project;OpenPlans
adr:;;1309 Ashwood Ave;Nashville;TN;37212;USA
email;internet:[EMAIL PROTECTED]
title:Lead Developer 
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: wicked update

[whit]

Martin Aspeli wrote:

whit wrote:
I'm pretty close to being ready to "merge" though I think that the 
actual merge may only be some snippets of zcml(and a few interface 
applications).


The kind of merge we like :)

made some good progress today and tied up a few existing loose ends. 
wicked can now be turned on and off via the persistent component 
registry.  I also implemented a media wiki style registration.


What is media wiki style registration?

basically, so you can choose [[linking]]  instead of ((linking)) for 
your site if you want to.  this was one of limi's requests.  To


All that is really left is to make a control panel(panel could 
probably wait though?).


Have you had a look at plone.app.controlpanel? Formlib galore :)

I'd say we can merge without a control panel but with sensible/safe 
defaults. Having the control panel would be a great bonus, though.


the infrastructure is pretty much there.  I'm handling the registration 
of "options" as classes[1] that are registered as entry points[2].  The 
class has methods for doing all the local component registering and 
unregistering as well as some metadata about what the bundle of 
registrations do.


I took a look at it and now that I'll gotten the architectural stuff 
done, will look at it some more.  I should be able to build vocabularies 
from the entry points to build the ui, and use the them on the backend 
to retrieve the classes and do the appropriate registrations.   One 
benefit of this approach is that an add on author can easily extend the 
control panel without having to override it in anyway. 


-w

_1: 
http://svn.plone.org/svn/collective/wicked/lib/wicked/trunk/wicked/registration.py
_2: 
http://peak.telecommunity.com/DevCenter/setuptools#dynamic-discovery-of-services-and-plugins




planning to get this wrapped up by this weekend if not sooner.


Excellent!

Thanks!

Martin


___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team



begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
org:The Open Planning Project;OpenPlans
adr:;;1309 Ashwood Ave;Nashville;TN;37212;USA
email;internet:[EMAIL PROTECTED]
title:Lead Developer 
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

[Framework-Team] wicked update

[whit]

I'm pretty close to being ready to "merge" though I think that the 
actual merge may only be some snippets of zcml(and a few interface 
applications).


made some good progress today and tied up a few existing loose ends. 
wicked can now be turned on and off via the persistent component 
registry.  I also implemented a media wiki style registration.


All that is really left is to make a control panel(panel could probably 
wait though?).


planning to get this wrapped up by this weekend if not sooner.

-w


___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Board-public] Re: [Framework-Team] Re: release schedule changes

[whit]

Personally, I never liked the separation of infrastructure/UI-focused
releases, and it was also something that was never voted on or
accepted as the way to go — it was just suggested. But if there is an
alternating schedule, 3.0 is definitely the UI release, not the
infrastructure release. ;)


I am thinking we need to be stricter about the alternating
infrastructure and UI releases in the future: currently we are still
doing both infrastructure and UI in a single release.


I don't think this will realistically ever happen if we're supposed to
have releases every 6 months. You can't add infrastructure like
versioning and ignore the UI aspect.

That being said, I haven't done my job in making the UI tasks clear to
the team, nor have I delivered what I hoped in terms of actual work.
Things have settled down now that I have finally started at Google, so
I suspect I will be more productive in the near future. I'm still a
bottleneck on the UI side, something I'm working on resolving (and the
UI sprint we have planned is a big part of that effort).

I think representing releases as binarily UI focussed or infrastructure 
focused does a bit of disservice to past discussions. The idea was more 
to have release that focused on new feature alternate with ones that did 
the needful and cleaned up accrued engineering debt. The idea that a 
release would ignore infrastructure or ui outright is ridiculous; the 
suggested structure merely gave a simple guiding principle on which a 
release would focus.


-w


begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
org:The Open Planning Project;OpenPlans
adr:;;1309 Ashwood Ave;Nashville;TN;37212;USA
email;internet:[EMAIL PROTECTED]
title:Lead Developer 
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] PLIP review overview

[whit]

172 should be ready for merging in a few days.

-w

Wichert Akkerman wrote:

I have gone over all the current reviews and divided them into three
sections: PLIPs ready for merging, PLIPs which need more work and not
yet reviewed PLIPs. Here we go:


PLIPs ready for merging
---

  PLIP   8 - Versioning 


   Stable product. There are possible improvements, but the current code
   is well structured and battle tested.

 
  PLIP 118 - Portlets engine based on PlonePortlets and Viewlets


Does deserve a good tutorial.


  PLIP 142 - Componentise the global content menu   


   Hanno found a few minor issues, which Martin mostly debunked. Remaining
   items are small and can be covered after an alpha released. Most important
   issue is backwards compatibility with older global_contentmenu
   customizations. Since Plone 3.0 is scheduled to get a new UI (of limi has
   this ready on time) this may be a non-issue since all templates may
   change.


  PLIP 148 - Move to CMF 2.1


   Raphael found some remaining TODO-items which Hanno has taken care of by
   now.


PLIPs not ready for merging
---

  PLIP  48 - Use session instead of cookie plugin to store PAS authentication   


   Old-style product, containing a lot of code to support non-PAS sites.
   Needs Cache-Fu updates.


  PLIP 112 - XML Import / Export


Export is not implemented. Only supports AT-based content, Zope 3 schema
based content and custom AT fields are not supported. Tests do not run.


  PLIP 127 - Move properties to Edit screen using pre-loaded fieldsets  


   dhtml-schemata branch needs merging into Archetypes. Grouping of
   properties has not been implemented yet. The content tabs need to
   be refactored.


  PLIP 145 - Locking


Event naming hs to be synchronized with iterate (PLIP 168). Removing
a lock on set by iterate on published content should not be easily
possible. Should switch to using evevnts instead of patching AT.
Possible needs extra extensionpoints in AT.


  PLIP 149 - Improved Markup SUpport

   allowable_content_types support needs work. Handle non-installed formats
   properly.
   

  PLIP 168 - integrate iterate for checkin/checkout/staging 


   Viewing a locked front page gave an error until the page was checked
   in.


  PLIP 172 - Wiki syntax support for all content


   Demo content types should be disabled. Needs integration into
   ATContentTypes with an option to switch it on and off.


  PLIP 174 - More configurable and reusable i18n features   


   TODO-items in the bundle need to be implemented.


  PLIP 179 - Improved commenting infrastructure 


   Interfaces need to be updated to be more flexible. Code needs to
   be refactored into a plone.commenting package. Work is well on its way.




PLIPs still under discussion


  PLIP 121 - Asynchronous loading of content views  


Implemented in both Bling and Azax/KSS. Needs a decision on the Ajax
framework to use for Plone 3.0.


  PLIP 122 - Edit-in-place mode for all basic field types   


Implemented in both Bling and Azax/KSS. Needs a decision on the Ajax
framework to use for Plone 3.0.


  PLIP 171 - KSS / Azax to Plone


   KSS/Azax are well designed and have very active developers. It is designed
   with developers in mind instead of copying patterns used by other frameworks.
   A sprint including non-azax developer has already happened, showing there is
   a very active group of people supporting this framework. Considering Bling
   has not seen much activity lately and its bundle does not work this looks
   like the best choice.

   


PLIPs not yet reviewed
--
  PLIP 119 - Contextual help portlet
  PLIP 125 - Ensuring link/reference integrity (removing 404 links) 
  PLIP 144 - Generalised Next / Previous navigation 
  PLIP 157 - Content rules engine   
  PLIP 173 - OpenID support 



Wichert.

  


begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
org:The Open Planning Project;OpenPlans
adr:;;1309 Ashwood Ave;Nashville;TN;37212;USA
email;internet:[EMAIL PROTECTED]
title:Lead Developer 
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Te

Re: [Framework-Team] Re: Error starting 3.0 bundle

[whit]

Daniel Nouri wrote:

whit wrote:
  
You could call it temporary in that Zope will hopefully get better at 
development eggs and therefore render a weaved-together bundle like this 
obsolete (instead, you'd have a bundle with eggs and then you'd 
easy_install each one). To be honest, I find the bundle fairly 
convenient though, just co and ln into lib/python.


  
currently, the only thing that zope does wrong with eggs is 
zope.testing.  if you use --test-path=/path/to/dev/egg, the test-runner 
will even work with eggs(though this is super annoying).


Now that the PYTHONPATH bug is fixed, you could conceivably just put the 
"plone-lib" dir on the PYTHONPATH and zope could find it.  Personally, I 
see this as a stop gap to doing the due diligence to get our own egg 
story sanified(and we should fix zope.testing on the way).


so really, this is our problem now, not zope's.



This is biting the Zope 3 people *right now*, too.  I wonder what
Philipp wrote in his the new edition of his book about eggs and tests.

I have been bitten by zope.testing too... :-/

  
I took a look at the zc.testrunner.recipe; it allows for the 
configuration of extra test paths (good if you know exactly what 
packages you will be working on).  The sensible behavior of nose is 
still missing; it seems explicit enough if I say test -s some.package I 
mean the tests that live in that package on my PYTHONPATH.  The current 
arrangement(in zope2) only searches lib/python and Products by default.


also, zope2 itself is just a few minor changes away from being egg 
installable itself at which point we should be able to deal with 
everything outside of Products via egg recipes.


my opinion is a little elbow grease to get this worked out now rather 
than later would go a long way. eggs are bit of pain, but we don't need 
to wait for any zope gods to descend from on high to make things better.


I mean... if you could say "easy_install Plone3=dev" and be ready to 
work, how cool would that be? Kevin Dangmoor attribute much of TG's 
success and rapid growth to making the packaging work.





+1

I really hope I can put some time into this in the following days.


  
awesome! this makes me feel better.  I truly do feel we aren't that far 
away from having a much happier packaging and dev situation than we have 
now.


-w
begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
email;internet:[EMAIL PROTECTED]
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: Error starting 3.0 bundle

[whit]

Daniel Nouri wrote:

whit wrote:
  
ugh... could we devote a little time to packaging love here? maybe at 
the conference? This is tipping my suckometer.


None of this is too fancy, but I think we've exceeded the utility of our 
bundle system and should fix our dev deploy story.


some notes in this arena::

* I just fixed the bug in all versions of zope that make you have to 
manually edit zopectl and runzope to use workingenv with zope.


* workingenv can take recipes of stuff to install in your environment



As far as I know, these recipes are simply Requirements in the
setuptools sense.  This is an example of a requirement (=recipe?):
https://svn.openplans.org/svn/training/pylons/requirements.txt
  
iirc, recipes for workingenv also take a '-r somefile-or-url' argument 
that allows for chaining of recipes.
  
* workingenv can checkout eggs in -e mode so you can have svn copies to 
work on.



Does workingenv checkout using -e *and* run python setup.py develop?
If so, I think I'd still usually prefer having one checkout of a
library regardless of how many other projects (or instances) use them.

  

not totally sure. have not had a chance to set this up for tagger.
* this mean all plone python deps need to be reasonable eggified; 
luckily this can be as easy as getting a properly formated link on a 
download page pointed at svn.  we could create omnibus packages 
though(makes working on stuff much easier).



I think there should be one Plone egg, namely "plone.app", that
depends on both all Python libraries (aka lib/python) and all Products
that Plone requires.  As far as the Zope 2 Products are concerned, I
believe that one egg to include them all should be enough.  I blogged
about making an egg out of all Plone Products [1].

Note that with workingenv, the installation procedure becomes a snap.
 One "plone.app" package depends on everything needed, and thus a
"easy_install Plone" is enough to download all dependencies.

  

* we would need to register our packages with PyPi



Which is really easy, because all the infrastructure is in place, see
[2] for example.

  

indeed.
* we would need to set up a page on plone.org with links that tell 
setuptools where to get the right packages.



+1

  
* we need to fix the retarded behavior of the zope testrunner that makes 
you explicitly state the test-path in order to run an egg's tests.



See the reply to your other mail.

  

* for Products, we could do a few different things:

   - use a custom zope skeleton(mkzopeinstance takes skel arg) that has 
a dev bundle for a Products dir.


   - use a symlink script like Rob's 
https://svn.openplans.org/svn/bundles/openplans-zope29-bundle/deploy.sh

 (does instancemanager do this too?)

* we need something to tie it all together(aka the download and execute 
this script):


   - create a buildout that creates a workingenv via our recipe, checks 
out the bundle, an makes zope with said bundle



I'm not sure if buildout is really necessary here.  I think we should
try and start simple, with a script that runs workingenv.py, creating
a working environment and Zope therein.  The same script could then
"easy_install Plone" in that workingenv and help the Plone packages in
lib/python put their zcml into the etc/package-includes directory.

I realize the last part with the zcml is ugly... and it is still ugly
when you use buildout.  However, this script should be easily
converted to a buildout recipe, if need be.

  

agreed.

-w


begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
email;internet:[EMAIL PROTECTED]
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

[Framework-Team] Re: PLIP145 Locking - Review

[whit]

Martin Aspeli wrote:

Hi Raphael,


While Sidnei is right in principle I again want to stress that the
hardest part here is to get some event triggered the moment the
user starts to work on something. With external edit its easy,
with a staging scenario its easy (as yuo do an explicit check out)
but for any Plone content item in general it's not that easy (or
at least I don't see it).



from the peanut gallery:

why not have ajax create the lock as soon as any richwidget get focus? 
for the non-ajaxy, have a lock button?


-w


___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

[Framework-Team] five.intid

[whit]

I'm assuming not only nouri might be interested in this...

after a bit of tickling, I got a acquisition friendly version of 
zope.app.intid working and checked in. it's ready to have it's tires 
kicked::


https://svn.plone.org/svn/collective/five.intid/trunk

as part of the package, it also includes a z2 compatibility layer for 
keyreferences.


if you don't know zope.app.intid, it's super simple; basically just a 
dual btree index that uses hashable objects as keys(and these objects, 
keyreference return a target object when called).  Registration and 
unregistering are handled by object event subscribers.  Adding an object 
via the subscribers fires an IIntIdAdded event for use in 
cataloging(there is an event for removal also).


I'm planning on using this with rdflib(as a catalog). tons of other 
reference oriented code from z3 uses it(zc.extrensicreference, 
zc.relationship, lovely.tag, etc).  If you wanted a more ATish UID, 
overriding the id generation in the utility would be trivial.


-w







___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: [PLIP 172 Wicked] Review notes

[whit]

thanks guys :)

some more thanks to limi, bcsaller, and alberto berti for the ideas and 
for rob getting me retroactive funding(and getting wicked from a 
prototype to a working release) and topp for funding the refactoring and 
recent work.


short roadmap
--

* couple zcml directives for::
  - txtfilter dispatch on arbitrary callable (so filter dispatch is by 
decoration rather than replacement or inheritance)

  - backlink dispatch on arbitrary callable

* making dispatch decorators able to toggle behavior on and off

* z3 utility for maintain state information for configlet

* configlet

* cachefu support(to kick documents with wicked links when links are 
resolved underneath)


* package reorganization of txtfilter and wicked to adhere to python 
package standards


on the longer road map

* getting wicked off the AT crack (maybe using five.intids)

* alternate resolvers (maybe a straight btree lookup or rdf)

* working on light framework for syntax extension(for tagging, explicit 
links, other forms of resolution)


* inplace content addition

* autocomplete list (possibly keyed on the beginning of a link "((" etc)

* link editing (ability to fix mis-resolved links and/or designate a 
link as a menu of alternative links)



-w

Alexander Limi wrote:
On Wed, 27 Sep 2006 07:02:42 -0700, Martin Aspeli <[EMAIL PROTECTED]> 
wrote:



Wicked is a wiki without all the cruft. It makes it simple to create
links-as-you-type, and keeps those links up-to-date when they move.
It's easy to use and quite innovative in that it integrates so
seamlessly into Plone.


Big props to Whit for turning my original late-night ramblings and 
thoughts about how wikis in Plone should work into a slick wiki 
implementation for Plone. Sometimes, ranting helps (well, it always 
helps — it's just not always it turns out changing anything ;).


Looking forward to being able to wiki-enable anything, even uploaded 
Word documents (I'm not kidding, this is actually possible - though 
whether it makes sense to you is another matter :).


--_

 Alexander Limi · Chief Architect · Plone Solutions · Norway

 Consulting · Training · Development · http://www.plonesolutions.com
_

  Plone Co-Founder · http://plone.org · Connecting Content
  Plone Foundation · http://plone.org/foundation · Protecting Plone



___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team



begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
email;internet:[EMAIL PROTECTED]
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

[Framework-Team] wiki syntax plip

[whit]

I've update the zope2.10 bundle and removed the zope2.9 bundle.  I left 
install instructions in BUNDLE-NOTES.txt along with a todo list.



-w


___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] [PLIP 149 Markup] - Review notes

[whit]

o It's unclear to me whether/how this corresponds to the work on Wicked

should be orthogonal to wicked (just as stx, reST, html etc is).  wicked 
is not format sensitive(another reason why it keeps it's syntactical 
scope limited).


speaking of wicked, got it all running with the plone-3.0 bundle this 
afternoon(and fixed a blocking bug for wicked's 1.0 release). currently 
doing a bit of cleanup and will update the bundle. sorry not to have 
this done earlier due to work constraints.


-w
begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
email;internet:[EMAIL PROTECTED]
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: Now what do we do?

[whit]

you might announce who is coordinate review on what bundles to plone-dev 
and encourage people to sign up.


as a non-voter, I'll volunteer to review 3 bundles.  anything but the 
wiki bundle. First come first serve. sign me up.


-w

Martin Aspeli wrote:

Helge Tesdal wrote:
On Wed, 30 Aug 2006 20:31:19 +0200, Martin Aspeli <[EMAIL PROTECTED]> 
wrote:


Glad you feel that way, I don't want to be seen to tell people what 
to do! Personally, though, I prefer to get a bit of a nudge rather 
than have to do all the leg work myself (and I was in need of a 
distraction).


Nudge is good.

Do we keep the list somewhere else than in mails? Like on plone.org 
or in SVN?


Once people agree, I'll put it in svn, in the review directory.

Martin

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team




___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Now what do we do?

[whit]

Our process could be improved.

we reviewed a few bundles a week over the course of a few weeks.
Basically, I or Alan would announce what bundles we were looking at and 
when the next phone call would be by email.   Since the process for each 
bundles was not specifically owned by anyone, the coverage of attention 
was a bit scattered imho and alot of time was wasted in rambling 
conference calls. cie la vie.


Since you have more bundles and more people, dividing the bundles among 
general areas of expertise might be a good idea.  If everyone owns the 
review of 2 or 3 bundles you should be well covered and then you have a 
point of contact for the bundle authors.   Not unlike SoC.


Key to the process is to draft as many people from outside the voting 
FWT to look at bundles and get their input.   Good job wiggy with the 
announcement.   This could be a good time to rouse up some enthusiasm 
about actually cranking out P3.


I recommend using a file in the svn bundle root as a comment trail: it 
is automatically web published, everyone should check out every bundle, 
all plone devs have write access to it, and conflict are merged(rather 
than blotted out or lost as in  a plone doc or email thread).  We used 
an email for each bundle that the group appended to by replying(post vote).


The worst part was getting people to make opinions in a timely fashion; 
I would recommend getting all opinions before the vote if possible. 
Having collected as many comments as possible before the vote makes 
voting faster and reporting the outcome easier.  We voted on the 
phone(sort of a waste of time imho); you might choose to use svn or 
email.  

Afterwards, someone (Marten in this case) compiles the votes and the 
various suggestions for next step and opinions into a usable report for 
that set of bundles and posts the report to plone-dev.   In the case of 
a rejection, someone should compile an explanation for the author of the 
package including what would need to be do for inclusion and a timeline 
for getting those things done.


lather, rinse, repeat.

Once you have completed this process for all the bundles, write wiggy a 
final report filled with guiding wisdom, make an announcement that you 
are disbanding as the voting board of the FWT, have a beer, scotch or 
coffee and at your leisure choose your successors for the next release.


-w


Martin Aspeli wrote:
So, the bundle deadline passed, and I almost got some sleep. I'm 
guessing a few bundles will trickle in still (Vincenzo is on holiday, 
for example, but promised to look at workflow)


Members from last year - how did you go about actually undertakign the 
reviews?


We have bundles at http://svn.plone.org/svn/plone/review/ (and one at 
svn.plone.org/svn/collective/easycommenting/bundles/2.5/ 
 
since Kai doesn't have commit privs yet).


This matches up pretty well to what we see in 
http://plone.org/roadmap, with a few exceptions. Most of these are 
excusable (AJAX dependencies that make no sense until we've sorted out 
that can of worms, trivial things that probably don't need much review 
- we'll have to take it on a case-by-case basis).


I know Wichert is away for 5 days, and Vincenzo is on holiday (until 
the middle/end of the week?). I'd be nice if we could come up with a 
process, though.


Martin


___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
  



___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Now what do we do?

[whit]

Wichert Akkerman wrote:

Previously Martin Aspeli wrote:
  

PLIP 173 - OpenID support
  


This one is mine. The current status shows the design nicely but there
are a couple of essential bits (like session authentication) still
missing (they are listed in the docs in the bundle). I expect it to be
fully stable in abou two weeks.

A reviewer will need to be be reasonably familiar with PAS plugins to be
able to review this I'm afraid.

Wichert.

  
hypothetically, the reviewer could own rounding up the information, say 
by sending someone who is good at PAS to take a look, and by asking 
wiggy lots of questions.


-w






___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Here a wiggy, there a wiggy

[whit]

I'm not sure there is any benefit to having a separation of powers 
here.   I would argue that the overlap in purpose actually makes 
sense(and due to that, there is a high probability that a FWT member may 
be a release manager).


Having the RM on the FWT may not be a necessity, but having the RM 
involved as a voting member (by happenstance) can only really serve to 
improve the communication between FWT and RM.in the end, we count on 
the release manager to be a benevolent dictator; the worst things that 
could happen is a RM totally ignore the FWT and be absent from all 
discourse.


The FWT serves as an instrument to aid the RM, a channel to enforce 
process, a buffer against organic groupthink decision making.   The 
process of review is the more important part, and as long as there are 
people with open ears who care voting, all is well.


-w

--

| david "whit" morriss 
|
| contact :: http://public.xdi.org/=whit 

"If you don't know where you are,  
 you don't know anything at all"

 Dr. Edgar Spencer, Ph.D., 1995 



"I like to write code like  
other ppl like to tune their 
cars or 10kW hifi equipment..."


Christian Heimes, 2004


begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
email;internet:[EMAIL PROTECTED]
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: Here a wiggy, there a wiggy

[whit]

We should get the voting from the Plone Foundation to make it a proper 
decision, though. Can any of you write up a recommendation and ask the 
Foundation for a vote? (I'd do it, but I'm really stretching myself to 
thin these days)
I sent a link to wiggy's wikipedia page to the board public list and 
asked for a prompt vote. 


I meanit's wiggy.  need we say more?

-w

--

| david "whit" morriss 
|
| contact :: http://public.xdi.org/=whit 

"If you don't know where you are,  
 you don't know anything at all"

 Dr. Edgar Spencer, Ph.D., 1995 



"I like to write code like  
other ppl like to tune their 
cars or 10kW hifi equipment..."


Christian Heimes, 2004


begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
email;internet:[EMAIL PROTECTED]
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: Names, names and we need a decision

[whit]

Martin Aspeli wrote:

Hi Hanno,

I'm happy to write the plone / plone.app announcement, and I can write 
the bit about guidelines for when to use them. However, I'm not too 
sure how we do the svn organisation.


 - are we recommending people use ZopeSkel?
cautious but enthusiastic non-fwt +1 here?  I'm hoping now that topp has 
Ian Bicking aboard we may have a chance of getting some expert cycles to 
resolve the skeletor/paste/zc.buildout/instancemanager overlap.  

but for creating basic stub skeletons ZopeSkel seems like the simplest 
starting point though.  I need to look at it again though; would we also 
need a ploneskel?


-w

--

| david "whit" morriss 
|
| contact :: http://public.xdi.org/=whit 

"If you don't know where you are,  
 you don't know anything at all"

 Dr. Edgar Spencer, Ph.D., 1995 



"I like to write code like  
other ppl like to tune their 
cars or 10kW hifi equipment..."


Christian Heimes, 2004


begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
email;internet:[EMAIL PROTECTED]
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: Release roadmap for 3.0

[whit]

Maybe moving to a pattern like this (peer-review) would also make
sense for us???


Just my 0.02 Euro

Raphael

i think that is essentially what we have.  in the end, the release 
manager decides.  the FWT is just a gatekeeper to make those decisions 
manageable.


-w

--

| david "whit" morriss 
|
| contact :: http://public.xdi.org/=whit 

"If you don't know where you are,  
 you don't know anything at all"

 Dr. Edgar Spencer, Ph.D., 1995 



"I like to write code like  
other ppl like to tune their 
cars or 10kW hifi equipment..."


Christian Heimes, 2004


begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
email;internet:[EMAIL PROTECTED]
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: Release roadmap for 3.0

[whit]

I think those are good points, and I certainly agree with the merits 
of having that separation be clear. I just wonder whether we truly 
*can* have such a separation, and whether there then is a vacuum in 
leadership and policy guidance that we need to fill, because I think 
people are expecting more than what we're expecting to give at the 
moment.
well, hopefully, by keeping the role of this team limited, all of you 
should be free to do the needful outside of the team in filling that 
vacuum.  and if people listen more because you are on the FWT, that 
doesn't hurt either as long as there is a clear separation.


one thing you guys(and all of us non-voters) can do is throw some rocks 
in the direction of marketing.  getting some people on the stick to fill 
that void *now* would make all the difference.  In proprietary software 
dev, marketting/product management drives the feature choices and 
therefore has a 6-12month drop on the release.  


so...send a letter to your local board member.

rocky has requested an end to philosophizing on this subject so I will 
respectfully end any comment hitherto.


-w

--

| david "whit" morriss 
|
| contact :: http://public.xdi.org/=whit 

"If you don't know where you are,  
 you don't know anything at all"

 Dr. Edgar Spencer, Ph.D., 1995 



"I like to write code like  
other ppl like to tune their 
cars or 10kW hifi equipment..."


Christian Heimes, 2004


begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
email;internet:[EMAIL PROTECTED]
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: Re: Release roadmap for 3.0

[whit]

for some reason, about 5 hours of mail got lost yesterday...so I did not 
see opti's originally reply to me.


Alec Mitchell wrote:

On 5/10/06, Martin Aspeli <[EMAIL PROTECTED]> wrote:

On Wed, 10 May 2006 21:05:04 +0100, whit
<[EMAIL PROTECTED]> wrote:

> /me dons grumpy old former FWT member hat
>
> remember, all that SoC stuff has to have bundles and be approved by 
you
> guys.  No implementing proposals after the fact.  That's about the 
only

> standing rule for this team.

I agree entirely.

> So if you are looking at this sort of
> schedule, likely almost none of the SoC stuff will go in until until a
> later 3.x release.

And, as I just replied to Rocky, this isn't something we can just take
lightly. It may not matter to you or me, but it matters a hell of a 
lot to

the guy who is debating whether to put the effort in to deliver some
killer feature. If the battle is lost before it's even begun, he won't
bother, and it'll more likely be 4.5 than 3.5 before it gets picked up
again (there's a reason why versioning is PLIP #8 and we have 157 PLIPs
spanning several years).

we've had this discussion before.  we can't promise anything will be 
going in, so it is better to not prematurely raise expectations.the 
example you use is a poor one. pick versioning, events, blogging 
etc.  these efforts haven't come to fruition to a myriad of factor that 
rarely include release planning or PLIPs.


arguably, one reason the framework team is in existence to remove 
inclusion of a developers code into CMFPlone as a motivation because in 
the past that motivation has proven to be a bad one because it 
encourages code dumping.  

it's just a bad carrot. 




> Also, 3.0 really should be just one louder than
> 2.5, regardless of the number.

I don't agree with this - and I don't think this was the intention with
the UI release/framework release split. As I recall it explained to me,
the plan was that .0 releases would be the big bang - once a year, we
release a new version of Plone with impressive new features, where we
progress and make some hard decisions about what we may need to break or
strongly deprecate to move Plone-the-product forward.


I don't think the sentiment that whit was expressing is really one
that you can disagree with.  It's a simple fact that we only have six
months for 3.0, and as a result there is a real limit on the amount of
stuff we can reasonably expect to include.  If we want if Five louder,
then we will need a lot more time.  However, because it is ui focused
the changes will be user visible, and therefore from a marketing
perspective it will be much "louder".  Nonetheless, there are real
limits on how much can be done, primarily determined by the number of
developers actively participating in the release and the time they are
capable of committing.  Fortunately, the Norway sprint and the SoC
project have potentially given us a fair amount more available
man-power than we had for 2.5.

see previous post.  I think we need to be carefully about inflating the 
impressiveness in the wrong quarters.  this is not our concern(granted, 
having some organized effective marketing leadership might help us not 
feel like we need to do something here. and maybe the framework team 
should consult with marketing and the foundation in a more official 
capacity). 

...

I'd argue that Plone-the-product, as far as end users is concerned, 
hasn't

really progressed very much since Plone 2.0. We still don't have
versioning, locking, staging, taxonomy/categorisation in anything more
sophisticated than a folder, we still have a very static UI, with many
slow page reloads, we have a fairly inflexible portlets infrastructure
that makes it awkward to make the CMS personalisable. And some of the 
cool

things we've talked about for years that real users really love, such as
contextualised help and actions, or UI improvements to selection widgets
and folder navigation, are still unrealised.

Meanwhile, there *is* competition. The big name right now is 
Alfresco, and
they are *killing* us on many aspects. We still have a stronger 
community,

we still have a better business model, we still have a better UI (though
their's ain't that bad). The other big one is (slightly awkardly) Rails,
where all the innovation in web UI seems to be happening. If Plone is to
survive, it needs to stay ahead of the curve, to be sexy and 
intuitive. It

also needs to avoid having too many red crosses in the feature matrices.


We all agree that there are a lot of great thing we should do, and
need to do in the long and short term.  But your job as the framework
team is to make a realistic assessment of what we can actually get
done in a 6 month time frame given the available resources.  What
Alfresco is doing and what customers are looking for in a CMS is at
most a 

Re: [Framework-Team] Re: Release roadmap for 3.0

[whit]

Martin Aspeli wrote:
On Wed, 10 May 2006 20:37:27 +0100, Rocky Burt <[EMAIL PROTECTED]> 
wrote:



Hmm... I'll let the date proposals stew in my mind for a little bit...
but just a comment on the SoC projects.  My feeling is that we shouldn't
assume *any* SoC project should make it into plone core for 3.0.  The
reality is that as Alec pointed out on irc today none of that stuff will
really have any chance to get battle-tested in the wild.


I think there are a three things to think about here:

 - Sometimes we build things in Plone that were built for Plone, and 
as such doesn't really have any decent chance of existing "in the 
wild" for some unspecified amount of time before we "integrate" it.


 - Some of the SoC projects are very directly related to PLIPs that we 
want to see completed for 3.0, and that were begun in Norway. 
Applicants with the appropriate skill and/or mentorship may well be 
able to have "good" (i.e. well-tested, well-designed) code in place 
for 3.0.


 - The .0 releases were always meant to be more revolutionary than the 
.5 releases. 3.0 *has* to be accompanied by a marketing push, and has 
to offer enough new features and fixes to old problems to entice 
people to upgrade not just because their Plone developer/consultant 
told it would would make their jobs a bit easier (which is what the .5 
releases are about, grossly exaggerated of course). Plus, there are a 
few things in Plone as it stands now that are just embarrassing by 
their omission. History shows us time and again that without ambitious 
targets, and without giving people a shared sense of purpose that we 
are stretching towards something great, no-one actually ever solves 
these problems.


For these three reasons, I think it's a very bad idea to send out the 
signal that the SoC code and the many great things that were begun at 
the Archipelago Sprint stand little chance of being ready in time and 
if even if they are, they will be met with scepticism. The elusive 
goal of a grand 3.0 release was the driving force in Norway, and will 
certainly be the driving force going forward. People don't spend their 
spare time on code that may or may not be used, at some time. But they 
put the effort in if they feel they have a responsibility to do so.


We need locking, seriously. We need a better portlets infrastructure. 
We need that to drive the dashboard, which we need to drive speed 
(non-cacheable portlets stay out of every bloody page and end up in a 
single, personal page). We need to AJAX-enable some of our UI to make 
it more responsive and easier to work with (and not seem so last 
century when people drool over Rails). We need link integrity, because 
broken links in a CMS are just embarrassing. We so much need to ship 
with workflows that actually make sense for the vast majority of use 
cases. We need to make it easier to collaborate on documents.


That may sound ambitious, but it is within our reach, with the right 
combination of sticks and carrots. A large part of that is showing the 
developers who are able to work on this the proper respect for their 
work, and at the same time demand the proper respect for our release 
schedule. There's a lot of pushing and teasing to be done for sure.


"But in my opinion, if it's November or December instead of October 
that's necessary to make this happen, that's a pretty small price to pay 
for a release that we can market as a great step forward, not just 
another trickle. "


I appreciate the enthusiasm, but 2 points:

1. code is ready when it is ready.  for projections made now, it is 
wiser to leave things that don't have bundles out of the equation.  
Better to have interesting releases across the 3.0 series. 

2. worrying about marketting and the "meaning" of release number imho 
has had a negative impact on discussion and effective planning in the 
past.  two things to remember in this regard::


- we have more features that have been released than have been marketed 
or made truly usable to the market we claim to be aiming at.  Therefore, 
needing to make the 3.0 release "marketable" is a non-starter to me (we 
need to get people to market).  Having one or two important features to 
focus on per release is more important than a ton of features.


- the meaning of a release is a marketing question.  if marketing says 
"we need SoC for publicity reasons", then it makes sense to wait. but 
otherwhise, this should just be a discussion of technical merit and 
preparedness.  the framework team should not be effected by the 
marketing vacuum.


-w




--

| david "whit" morriss 
|
| contact :: http://public.xdi.org/=whit 

"If you don't know where you are,  
 you don't know anything at all"

 Dr. Edgar Spencer, Ph.D., 1995 



"I like to write code like  
oth

Re: [Framework-Team] Re: Release roadmap for 3.0

[whit]

/me dons grumpy old former FWT member hat

remember, all that SoC stuff has to have bundles and be approved by you 
guys.  No implementing proposals after the fact.  That's about the only 
standing rule for this team. So if you are looking at this sort of 
schedule, likely almost none of the SoC stuff will go in until until a 
later 3.x release.   Also, 3.0 really should be just one louder than 
2.5, regardless of the number. 

I would argue that the proposal freeze *is* the feature freeze *is* the 
last date that the framework team accepts bundles for review.


remember also, release manager makes all the dates and decisions except 
for the due date for bundle submission.



-w


Rocky Burt wrote:

On Wed, 2006-10-05 at 20:58 +0200, Hanno Schlichting wrote:
  

Plone 2.5
-
May 2006, announced release
June 2006, expected release

CMF
---
April 2006, 2.0
July 2006, 2.1 (planned)

Zope

May 2006, 2.9.3
June 2006, 2.10
November 2006, 2.11
May 2007, 2.12

Plone 3.0
-
June 26, proposal freeze
August 21, feature freeze
October 22, announced release

The good thing about this is that we should get all the great work done
as SoC projects into the release, the negative thing is that we are
again quite behind the schedule in regard to our stack, as both the
releases of Zope and CMF we will build on are already due in June/July.
But I don't see how we could get the good things from SoC into the
release with some reasonable feedback and testing if we would aim for an
earlier release.



Hmm... I'll let the date proposals stew in my mind for a little bit...
but just a comment on the SoC projects.  My feeling is that we shouldn't
assume *any* SoC project should make it into plone core for 3.0.  The
reality is that as Alec pointed out on irc today none of that stuff will
really have any chance to get battle-tested in the wild.

I'm more concerned with staying within reasonable dates with the rest of
our stack.  It frustrates me to no end we keep lagging behind our stack
releases so much (I know 2.5 and 3.0 will fix some of that).

- Rocky


  



___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
  



--

| david "whit" morriss 
|
| contact :: http://public.xdi.org/=whit 

"If you don't know where you are,  
 you don't know anything at all"

 Dr. Edgar Spencer, Ph.D., 1995 



"I like to write code like  
other ppl like to tune their 
cars or 10kW hifi equipment..."


Christian Heimes, 2004


begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
email;internet:[EMAIL PROTECTED]
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: Viewlets

[whit]

Martin Aspeli wrote:

On Sat, 08 Apr 2006 05:40:48 +0100, whit <[EMAIL PROTECTED]> wrote:


considering we are jumping from 2.5 -> 3.0, we have some play.

there is no reason that there can't be releases in between 2.5 and 3.0.
Let's use those numbers to get ourselves back in sync with the rest of
our stack.  depending on when thing fall, 2.6, 2.7, 2.8, and 2.9 could
serve as a way to ease onto CMF2.0, zope 2.10, AT1.4 & 1.5, Five 1.5,
etc.


I'm not sure where this came from... 3.0 has a release date and a plan 
that doesn't allow for a four more releases to be completed and tested 
in time. I think it's extemely unlikely we'll see a Plone 2.6 or a 
Plone 2.7 unless someone seriously commits to doing the needed 
integration work and manages that release. Each release cycle brings 
with it serious overheads of betas, rcs, bug days, migration work etc.


I'm not an expert at release management, but it seems that how serious 
the overhead would depend on how serious the changes to plone need to be 
to make them run on the new stack layers. at some point, someone will 
have to commit to doing this work, and it would be better to be before 
said stack layer is approaching unsupported obsolescence.  I'm not 
saying that it will necessarily be expedient between now and the release 
of 3.0, I'm just saying the numbers are there, and we can use them to 
pad the way to things that might suit the 3.0 release best.


free unspoken for numbers if we happen to need them.   but this is a 
divergent topic.


Which brings us back to the original point. If Plone 3.0 is supposed 
to be an end-user experience focused release, part of that is to make 
sure that third party products can integrate well into the Plone UI 
without having to override major templates like global_contentmenu or, 
worse, main_template. I *want* to see 
classification/taxonomy/ontology/tagging/whatever in a way that's 
generic and usable, and I want to make it possible for products like 
LinguaPlone and CMFEditions to inject things into the Plone UI without 
that having to be un ugly hack.



which brings up back to viewlets...
I'm happy to support Zope 2.10 only in 3.0 if that's stable and out 
the door, though (not that it's my call).


For our current use cases, the main use of viewlets will be to render 
them - the update phases are probably less interesting for now. We 
*may* be able to support a trade-off where we use the viewlet API but 
support only rendering. I'm not sure yet, though - we really need to 
speak to someone (Stephan Richter?) who knows how viewlets work a 
little better.
or trying implementing a couple. 


-w

--

| david "whit" morriss 
|
| contact :: http://public.xdi.org/=whit 

"If you don't know where you are,  
 you don't know anything at all"

 Dr. Edgar Spencer, Ph.D., 1995 



"I like to write code like  
other ppl like to tune their 
cars or 10kW hifi equipment..."


Christian Heimes, 2004


begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
email;internet:[EMAIL PROTECTED]
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Viewlets

[whit]

Rob Miller wrote:

On Apr 7, 2006, at 8:54 PM, whit wrote:

Martin Aspeli wrote:

Hi guys,

I'm thinking about several things I'd like to enable in Plone 3.0, 
and the concept of using viewlets is really attractive. For example, 
the contentmenu (the green one, with actions and state and add 
item): It's impossible to add a new drop-down without overriding the 
entire thing. In general, this could be solved by having the whole 
menu be rendered as a viewlet manager, with each menu provided by a 
viewlet. You could then register new viewlets to get new menus.


I've only read through the READMEs of zope.contentprovider 
(http://svn.zope.org/Zope3/trunk/src/zope/contentprovider/README.txt?rev=66018&view=markup) 
and zope.viewlet 
(http://svn.zope.org/Zope3/trunk/src/zope/viewlet/README.txt?rev=41173&view=auto), 
and probably should do so again.


I wanted to ask, though, if any of you have got some experience with 
viewlets and would like to discuss it further? In particular, we 
need to work out whether we could:


 - use them in 3.0  directly (unlikely, since it requires a 
provides: TAL namespace, which probably requires the Zope 3.x TAL 
implementation that may or may not land in Zope 2.10)
+1. this is the right thing to do.  it might require more work but 
until it's been tried and tracer bullets have been fired, everything 
else is a premature hack.  I realize this isn't much of a way to 
start discussion, but personally I think investigation is more 
important at this point.


philikon said he would add it in  in Five 1.5 if someone did the 
work.  maybe by plone 3 we can actually release on the current 
version of Zope, and I believe that the zope3 tal engine will be in 
2.10.


Plone 2.5 will support the most current version of Zope, unless 
there's been a 2.10 release that i missed somewhere.


i'm +1 on using viewlets for this, but i don't think we'll be able to 
do it by relying on the zope 3 TAL implementation.  especially not if 
we're going to continue our current policy of supporting two major 
Zope revisions, in which case we'll have to straddle 2.9 and 2.10 w/ 3.0.


considering we are jumping from 2.5 -> 3.0, we have some play. 

there is no reason that there can't be releases in between 2.5 and 3.0. 
Let's use those numbers to get ourselves back in sync with the rest of 
our stack.  depending on when thing fall, 2.6, 2.7, 2.8, and 2.9 could 
serve as a way to ease onto CMF2.0, zope 2.10, AT1.4 & 1.5, Five 1.5, 
etc.  


-w

--

| david "whit" morriss 
|
| contact :: http://public.xdi.org/=whit 

"If you don't know where you are,  
 you don't know anything at all"

 Dr. Edgar Spencer, Ph.D., 1995 



"I like to write code like  
other ppl like to tune their 
cars or 10kW hifi equipment..."


Christian Heimes, 2004


begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
email;internet:[EMAIL PROTECTED]
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Viewlets

[whit]

Martin Aspeli wrote:

Hi guys,

I'm thinking about several things I'd like to enable in Plone 3.0, and 
the concept of using viewlets is really attractive. For example, the 
contentmenu (the green one, with actions and state and add item): It's 
impossible to add a new drop-down without overriding the entire thing. 
In general, this could be solved by having the whole menu be rendered 
as a viewlet manager, with each menu provided by a viewlet. You could 
then register new viewlets to get new menus.


I've only read through the READMEs of zope.contentprovider 
(http://svn.zope.org/Zope3/trunk/src/zope/contentprovider/README.txt?rev=66018&view=markup) 
and zope.viewlet 
(http://svn.zope.org/Zope3/trunk/src/zope/viewlet/README.txt?rev=41173&view=auto), 
and probably should do so again.


I wanted to ask, though, if any of you have got some experience with 
viewlets and would like to discuss it further? In particular, we need 
to work out whether we could:


 - use them in 3.0  directly (unlikely, since it requires a provides: 
TAL namespace, which probably requires the Zope 3.x TAL implementation 
that may or may not land in Zope 2.10)
+1. this is the right thing to do.  it might require more work but until 
it's been tried and tracer bullets have been fired, everything else is a 
premature hack.  I realize this isn't much of a way to start discussion, 
but personally I think investigation is more important at this point.


philikon said he would add it in  in Five 1.5 if someone did the work.  
maybe by plone 3 we can actually release on the current version of Zope, 
and I believe that the zope3 tal engine will be in 2.10.


-w

--

| david "whit" morriss 
|
| contact :: http://public.xdi.org/=whit 

"If you don't know where you are,  
 you don't know anything at all"

 Dr. Edgar Spencer, Ph.D., 1995 



"I like to write code like  
other ppl like to tune their 
cars or 10kW hifi equipment..."


Christian Heimes, 2004


begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
email;internet:[EMAIL PROTECTED]
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: PLIP wishlists towards 3.0

[whit]

Rob Miller wrote:

On Mar 13, 2006, at 12:21 PM, Sidnei da Silva wrote:


On Mon, Mar 13, 2006 at 12:03:52PM -0800, Rob Miller wrote:
| hmm... not sure i can, actually.  i'm very interested in getting this
| working, and i'll provide guidance and help, of course, but i expect
| i'll be pretty busy focusing on member management and general cmf 2.X
| related stuff, this may be more than i can commit to.
|
| sashav tried to get kapil's GenericSetup-based ContentSetup product
| working at the snow sprint, but failed, and ended up having better
| success w/ jens's XMLForest product.  maybe we can get more help from
| him.  and maybe i'll have more time than i think, who knows, but i
| would recommend against counting on me for this.

The advice I can provide here is that any framework that doesn't use
Archetypes marshallers is a waste of effort.

'Marshall' the product just enables to multiplex Archetypes 'marshall'
by moving policy about what marshaller to use outside the schema. It
is *not* a/the solution itself, it just allows different solutions to be
implemented on top of it.

The reason for using Archetypes marshaller infrastructure instead of
'' is that:

1. It plays well with WebDAV and FTP
2. WebDAV and FTP are best ways to import and export content from
   Plone, if not because they are born to the task because using a
   browser just won't scale.
3. We at Enfold Systems are committed to make sure Zope 2 and Zope 3
   have efficient, memory-savy, speedy and featureful WebDAV and FTP
   experience, because It's Our Core Business (TM).


works for me.

-r

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

was there a non-marshall based IO piece suggested? iirc, everything 
talked about so far is based on marshall.


-w

--

| david "whit" morriss 
|
| contact :: http://public.xdi.org/=whit 

"If you don't know where you are,  
 you don't know anything at all"

 Dr. Edgar Spencer, Ph.D., 1995 



"I like to write code like  
other ppl like to tune their 
cars or 10kW hifi equipment..."


Christian Heimes, 2004


begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
email;internet:[EMAIL PROTECTED]
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] 3.0 shouldn't just be about the user facing UI

[whit]

Helge Tesdal wrote:

On Mon, 13 Mar 2006 18:18:20 +0100, whit <[EMAIL PROTECTED]> wrote:


My personal feeling(somewhat reinforced by what I saw at the symposium)
is that our ui layer is on a crash course with it's self.  At best, this
offers an opportunity to rethink how we want to work with UI as
developers, designers, integrators, etc before stumbling into a system
shaped by the assumptions of the old one.


I tend to prefer the complete rethink, so I'd like a discussion on how 
we're doing UI and how we want to do UI. :)

this is what I'm advocating, the discussion that I think needs to happen.

-w

--

| david "whit" morriss 
|
| contact :: http://public.xdi.org/=whit 

"If you don't know where you are,  
 you don't know anything at all"

 Dr. Edgar Spencer, Ph.D., 1995 



"I like to write code like  
other ppl like to tune their 
cars or 10kW hifi equipment..."


Christian Heimes, 2004


begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
email;internet:[EMAIL PROTECTED]
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

[Framework-Team] 3.0 shouldn't just be about the user facing UI

[whit]

just to piggy back a bit on this:

I think one consideration that needs to be made is how much you guys 
want to start pursuing new style development.  By the time Plone 3 
ships, CMF 2.0 will have full customization of views(the technology is 
not far off as we stand now). 

My personal feeling(somewhat reinforced by what I saw at the symposium) 
is that our ui layer is on a crash course with it's self.  At best, this 
offers an opportunity to rethink how we want to work with UI as 
developers, designers, integrators, etc before stumbling into a system 
shaped by the assumptions of the old one.


to summarize some of my past opinions: 
1.  developers designing UI's for designer to do ui is bad. 
2. designers waiting to learn new ways of doing UI until a "best 
practice" is established prevents them from weighing in on the 
aforementioned.
3. systems like mcdonc's z3meld and five views could go a long way to 
clearing up the plone ui mess, but only if they can gain adoption.


no final solutions are needed here, just some thinking about the 
problem.  the archipelago would be a good place for those of you who are 
more technical to discuss this with the more design oriented.


-w

--

| david "whit" morriss 
|
| contact :: http://public.xdi.org/=whit 

"If you don't know where you are,  
 you don't know anything at all"

 Dr. Edgar Spencer, Ph.D., 1995 



"I like to write code like  
other ppl like to tune their 
cars or 10kW hifi equipment..."


Christian Heimes, 2004


begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
email;internet:[EMAIL PROTECTED]
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: zope "two visions" info

[whit]

Martin Aspeli wrote:
On Thu, 02 Mar 2006 17:31:06 -, Rocky Burt 
<[EMAIL PROTECTED]> wrote:



Hi guys,

There's an active thread going on on the zope3 mailing list these past
few days regarding the vision of zope 2 and zope 3 started by Jim Fulton
where he positions building the next generation app server from zope 2
and having zope 3 become a framework/library only.


I've been trying to follow this discussion (though discussions on 
z3-base tend to become ridiculously long). I quite like Joel Moxley's 
idea about shpping Zope 3 CA, and then Zope 3 Server that sits on top 
of the CA. Actually, the way it looks like this is going is simply to 
break Zope 3 into smaller pieces (probably as eggs), from which we 
will be at liberty to choose what we want. At the same time, I'm 
hoping that more pieces of the Zope3-the-appserver will be folded back 
into Zope2.


I think that Jim's "Zope 5" (bad name) idea is basically where we've 
been going with Zope 2.8+ and Five, so I'm not really seeing any cause 
for alarm. I may be missing some subtler points here... but in 
general, more componentisation is probably better as far as I'm conerned.


What are your thoughts?

Martin



first, haven't had time to read the whole thread.  followed the
conversation on z3-base yesterday.  my opinion is the following in a broad 
strokes:

my view of the discussion:

1. we need to support jim when he pays attention to zope2 development
2. zorp corp et al. investing more in zope 2 can only help us.


my view broadly:

1. having 2 appservers named zope is bad
2. most pure z3 dev people want libs not an appserver
3. most z2 people have there wagons hitched to an appserver(or they wouldn't be 
doing zope2)


my views on direction (this will sound simplistic):

1. let zope be a namespace
2. converge the two platforms to be one appserver
3. f*ck calling any of it zope ;)


my personal feeling is let zope2 be it's own bw-compat layer by evolving zope the appserver so you can choose to use what you need of it (sort of like using CMF if you need plone, or plone if you need PHC, etc). 

-w 







| david "whit" morriss 
|
| contact :: http://public.xdi.org/=whit 

"If you don't know where you are,  
 you don't know anything at all"

 Dr. Edgar Spencer, Ph.D., 1995 



"I like to write code like  
other ppl like to tune their 
cars or 10kW hifi equipment..."


Christian Heimes, 2004


begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
email;internet:[EMAIL PROTECTED]
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] zope "two visions" info

[whit]

Rob Miller wrote:

On Mar 2, 2006, at 10:02 AM, whit wrote:

my suggestion along these lines was to start by firing a shot over 
the z3 bow by saying "hey, we are the pfwt, we're concerned, we're 
going to discuss this amongst plone developers"


just so they know there are eyes on the subject even if we haven't 
said anything.  then you guys can start the conversation here amongst 
the team and the larger plone-dev community and it if take a little 
while to get consensus, there will be nobody saying "well you didn't 
speak up" later.


i'm not 100% behind a monolithic plone framework team opinion.  i 
think chatting about it in this venue is fine, and if there _is_ 
consensus, great, that can be used, but i also think each person 
should be encouraged to speak from an individual voice, as well.


-r


yeah, I think that's fair...

Something as simple as letting the z3 side know that plone and the 
framework team has been discussing this is more important symbolically 
than having a unified response. 

just because everyone else charges in guns blazing doesn't mean we have 
to. and this debate could really effect plone more than almost anyone 
else, so at looking before leaping isn't a bad idea.  at least we should 
know the ups downs of what other think to inform an effective response.


I would say that helping generate some opinions on the plone side and 
expressing them on the z3 side would be the most important thing here.  
I would say the framework team is somewhat charged with the roles of 
representing those that don't know enough to care in this situation, and 
figuring out a way to get that information on their needs is what is 
called for.


just my $.02

-w

--

| david "whit" morriss 
|
| contact :: http://public.xdi.org/=whit 

"If you don't know where you are,  
 you don't know anything at all"

 Dr. Edgar Spencer, Ph.D., 1995 



"I like to write code like  
other ppl like to tune their 
cars or 10kW hifi equipment..."


Christian Heimes, 2004


begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
email;internet:[EMAIL PROTECTED]
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] zope "two visions" info

[whit]

my suggestion along these lines was to start by firing a shot over the 
z3 bow by saying "hey, we are the pfwt, we're concerned, we're going to 
discuss this amongst plone developers"


just so they know there are eyes on the subject even if we haven't said 
anything.  then you guys can start the conversation here amongst the 
team and the larger plone-dev community and it if take a little while to 
get consensus, there will be nobody saying "well you didn't speak 
up...." later.


-w

--

| david "whit" morriss 
|
| contact :: http://public.xdi.org/=whit 

"If you don't know where you are,  
 you don't know anything at all"

 Dr. Edgar Spencer, Ph.D., 1995 



"I like to write code like  
other ppl like to tune their 
cars or 10kW hifi equipment..."


Christian Heimes, 2004


begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
email;internet:[EMAIL PROTECTED]
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Putting a frame on the AJAX discussion

[whit]

Martin Aspeli wrote:

Hi guys,

I'm quite intrigued by the AJAX discussion going on, and I'd like it 
to be left alone to play out for a little while longer, but I'm also 
struggling to understand it and put it in context. I'm guessing others 
may feel the same.


So I thought, why not offer an "AJAX challenge". Let's list a few 
things we'd like to do with AJAX in Plone, such as an AJAX navtree, a 
better LiveSearch and limi's ÜbserSelectionWidget idea, drag-and-drop 
folder re-ordering, drag-and-drop copy/move of objects, in-place 
editing of Archetypes fields or tab-switching without reloading the 
page (those are the big ones I can think of now, anyway). Then we'll 
invite proponents of various approaches to submit some information on 
how they'd solve one or a few or all of those with their solution of 
choice, and ask some tough questions, around i18n, l10n, ability to 
fall back on a non-JS version, what the developer needs to learn, how 
hard it will be to customise templates using these types of features, 
how much it would add to the download of a plone page in added JS etc.


I'm hoping for something more than "look at this vaguely related code 
in svn" because that puts all the work of putting the pieces back 
together on the reader, and I don't think we'll get enough people 
understanding it well enough for that to be effective. However, we 
also wouldn't need full working implementations, just enough 
background and informed guessing that we can make an informed decision.


Do you think this is a good idea? How would you like to conduct it? Is 
this a potentially useful role for the framework team to play when 
there are important descisions to be made like these that perhaps not 
everyone fully understands?
it's worth a try. 

I would say your role is to facilitate making your later decision easier. 

in that light what I'd  suggest is put it those doing ajax (ben, gotcha, 
florian, rocky, etc) and let them run the challenge (since I think we 
probably want them working together to figure out where their approaches 
complement and overlap since the problem being solved are not exactly 
interchangeable).It encourages collaboration, and those doing js 
will hopefully arrive at the same conclusion at the end of how things 
should work.


then all you have to do is rate the quality of the work that comes in 
having delegated the decision to those with expertise.


just my .02

-w

--

| david "whit" morriss 
|
| contact :: http://public.xdi.org/=whit 

"If you don't know where you are,  
 you don't know anything at all"

 Dr. Edgar Spencer, Ph.D., 1995 



"I like to write code like  
other ppl like to tune their 
cars or 10kW hifi equipment..."


Christian Heimes, 2004


begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
email;internet:[EMAIL PROTECTED]
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

[Framework-Team] upcoming cms sprint

[whit]

roger ineichen ask me to forward this to you guys::

http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/SwissEasterSprint

If any of you have time, I think it would be *great* to get some plone people 
there (especially those of you who did not have a chance to meet or work with 
stephan and roger in Egg).  I believe russ feriday is going to try to be there 
too.

for those of you without deep z3 experience, this is a fast and easy way to get 
it.  and this sprint also has the potential to be very important in the general 
course of CMS in the zope world.

-w

--

| david "whit" morriss 
|
| contact :: http://public.xdi.org/=whit 

"If you don't know where you are,  
 you don't know anything at all"

 Dr. Edgar Spencer, Ph.D., 1995 



"I like to write code like  
other ppl like to tune their 
cars or 10kW hifi equipment..."


Christian Heimes, 2004


begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
email;internet:[EMAIL PROTECTED]
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

[Framework-Team] new framework team

[whit]

I'm proud to present to you the new voting members of the framework team.  Based on interest, we have a well rounded seven!  



FWT II 



Wichert Akkerman
Martin Aspeli
Rocky Burt 
Raphael Ritz

Hanno Schlichting
Vincenzo Di Somma
Helge Tesdal

This voting body is effective now. In their first vote, they elected Martin Aspeli to act as the official spokesperson for the group.  You, plone-at-large, may start submitting PLIPs w/ code bundles for their review for inclusion in Plone 3, the (enter tagline here). 


-
FAQ
-

To clarify any confusion, I've included some answers to some frequently asked 
questions.


Q: What does the framework team do?

A: the framework team is responsible for recommending code for inclusion in a Plone release to that release's manager.  In the release cycle, they drive the PLIP and bundle code review cycle.  


The voting members do the formal duty of collecting information from the 
community about bundles offered for review, and making the formal decision by 
voting whether to recommend them to the release manager.  One member of the 
group is chosen from within the group as the framework team lead and is 
responsible for communicating all decision of the team onto the plone-devel 
list.


Q: Who is on the team?  


A: Anyone who wants to review code and is interested in actively participating 
with shaping the technical vision of Plone's future. Each release, a small 
group in a similiar timezone is chosen to cast the actual votes on 
proposals(PLIP + bundle) on the advise of the larger team.


Q: How/when are the voting members chosen?

Currently, voting members are chosen arbitrarily on a rigorous *wink* criterion 
of general interest, recent contribution, timezone and who the former voting 
members thought would do a good job.  As the framework team is dedicated to 
evolving process, this is open to become a more formalized democratic process.

New voting members are active after the first alpha of a new release and remain 
active until the first alpha of the next major release.


Q: What happened to the old framework team?

A: The former voting members are still part of the team and will help out with 
code review.  Whit Morriss (aka me) has offered to stay on as a non-voting 
member(oxymoron, yes) to help with continuity and as a community liaison (read, 
svn-nanny).


Q: Sounds groovy! How can I participate? (I just can't get enough e-mail from 
Martin...)

A: Thought you would never ask... the new voting member probably have some 
ideas, but here are some broad strokes that go from early in the release cycle 
to late:

 * Participate in / start technical discussions of possible PLIPs on 
plone-devel (preferably with prototype code).  This also includes discussions 
of use-cases and end-user needs.

 * Join framework-team@lists.plone.org and participate in discussions of 
refining development process and codification of developer best practices.

 * As plips come in, help plippers make bundles and prepare their code for 
review.

 * As bundles get ready for review, review code and report your findings to the 
voting members.

 * take off your framework-team hat and help get that release out!

If after this the experience moves you, and you want to bear the responsibility 
of voting and encouraging others to review code, let the current lead know of 
your interest.


cheers!

-w





___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: Plone core developer manual

[whit]

vds, helge?

-w

Rocky Burt wrote:

Martin Aspeli wrote:
  

Raphael Ritz <[EMAIL PROTECTED]> writes:




whit wrote:


  

[..]
also, you guys need to pick a mouthpiece responsible for representing 
the group and then I can make a grand announcement of your existence.


Again, I propose Martin for this, if he is available.
 Martin: would you be willing to do this?
  

If there's one thing I do, it's yap on a lot. I'm happy to take on this role if
people want me to do it.



+1



  



--

| david "whit" morriss 
|
| contact :: http://public.xdi.org/=whit 

"If you don't know where you are,  
 you don't know anything at all"

 Dr. Edgar Spencer, Ph.D., 1995 



"I like to write code like  
other ppl like to tune their 
cars or 10kW hifi equipment..."


Christian Heimes, 2004


begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
email;internet:[EMAIL PROTECTED]
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Plone core developer manual

[whit]

Martin Aspeli wrote:

Hi guys,

A while ago, I started this reference manual 
http://plone.org/documentation/manual/plone-developer-reference


w00t!  I'm not sure alan got your reference into the appropriate place, 
but the intention was to put this and similar info into 
plone.org/developers .   And all of you should have access to extend and 
edit this section of the website.
The intention was to make a single places for Plone core developers to 
find the information they need on how to contribute, and how they 
should be coding. The idea was to cover three things:


 1. How do I contribute to Plone? How do I write a PLIP, make a review 
bundle, get access to svn etc.


 2. How do I write Plone code? Things like unit testing, migrations, 
coding style etc.
this will be very important in the near term, since best practices of 
the last 2 + years are going to be changing a bit.


 3. Explanation of some of the Plone specifics that are non-trivial to 
understand by simply skimming the code, like the 
ExtensibleIndexableObjectWrapper, the BrowserDefault jungle, portal 
setup etc.


Now, 1. is covered in part at http://plone.org/development/info/ and 
http://plone.org/development/dev-summary.


I think some of the above needs to be refactored a little. I'd like to 
have a distinction between overview-style documentation (e.g. what is 
a bug day, what is a sprint) from the specifics (how do I use Plone 
svn etc.). The overview in the dev-summary document, which covers 
third party developers as well, ought to stay where it is. However, 
some of the specifics in the various documents under /info would 
probably slot better into a real manual. I think giving people more 
focused documentation (that's part of the documentation area) would 
make it easier for people to contribute.


What do you guys think? I'm hoping to have some time to put into this 
in the next few days and weeks, and I'm hoping other will want to help 
as well.


If you guys are up to it, it's a definite need.  I would encourage you 
to also look at the process and technology you are documenting and think 
"If I was a new developer, would this seem sensible and easy, or 
overwhelming?"   The answer to that question might be the ground for new 
PLIPs (for instance, BrowserDefault and EIOW could both benefit from 
using the CA rather than their old school component approach).


also, you guys need to pick a mouthpiece responsible for representing 
the group and then I can make a grand announcement of your existence.


-w

--

| david "whit" morriss 
|
| contact :: http://public.xdi.org/=whit 

"If you don't know where you are,  
 you don't know anything at all"

 Dr. Edgar Spencer, Ph.D., 1995 



"I like to write code like  
other ppl like to tune their 
cars or 10kW hifi equipment..."


Christian Heimes, 2004


begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
email;internet:[EMAIL PROTECTED]
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

[Framework-Team] Re: the magnificent seven

[whit]

whoops...

-w

Raphael Ritz wrote:

Martin Aspeli wrote:


I like this list :)


Great. But I hope it's not only because your name
is misspelled down there ;-)

Raphael



On 2/9/06, *whit* <[EMAIL PROTECTED] 
<mailto:[EMAIL PROTECTED]>> wrote:


ok, if any of you don't want to do this, speak now.

It is my pleasure to make this internal announcement of the new
framework team!

Wichert Akkerman
Marten Aspeli
Rocky Burt
Raphael Ritz
Hanno Schlichting
Vincenzo Di Somma
Helge Tesdal







--

| david "whit" morriss 
|
| contact :: http://public.xdi.org/=whit 

"If you don't know where you are,  
 you don't know anything at all"

 Dr. Edgar Spencer, Ph.D., 1995 



"I like to write code like  
other ppl like to tune their 
cars or 10kW hifi equipment..."


Christian Heimes, 2004


begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
email;internet:[EMAIL PROTECTED]
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

[Framework-Team] the magnificent seven

[whit]

ok, if any of you don't want to do this, speak now.

It is my pleasure to make this internal announcement of the new 
framework team!


Wichert Akkerman
Marten Aspeli
Rocky Burt
Raphael Ritz
Hanno Schlichting
Vincenzo Di Somma
Helge Tesdal

Note that team size has grown by two.  Due to interest, and because I 
think it's easier to get 5 at a meeting for a vote if seven are 
obligated, we have mildly expanded from the original team.


I have pledged to stick around are a non-voting participant to help 
preserve continuity, and as alway, anyone interested in the architecture 
of plone is welcome to participate in creating process and, of course, 
reviewing code.


-w

--

| david "whit" morriss 
|
| contact :: http://public.xdi.org/=whit 

"If you don't know where you are,  
 you don't know anything at all"

 Dr. Edgar Spencer, Ph.D., 1995 



"I like to write code like  
other ppl like to tune their 
cars or 10kW hifi equipment..."


Christian Heimes, 2004


begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
email;internet:[EMAIL PROTECTED]
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

[Framework-Team] next framework team

[whit]

I've contacted rocky burt, marten aspeli, hanno schlicting, jen klein, 
stefan holek, and godfroid Chapelle, and helge tesdal.   This list is 
based on conversations with many of you (but probably not all).   
Suggestions about how to make this a more democratic / less arbitrary 
process are welcome but the former team promised to take care of this, 
and I am fufilling that promise.


I am assuming an attrition rate of 2, and gotcha has offer parental 
supervision with the proviso that he has limited bandwidth.  If you know 
of people who would be good for this team, or would like to volunteer 
yourself, please speak up so we either draft you now or later.


No plips or bundle exist yet for plone 3, so this may give the new team 
and old team some time to strategize how to make this process more 
effective. 


-w

--

| david "whit" morriss 
|
| contact :: http://public.xdi.org/=whit 

"If you don't know where you are,  
 you don't know anything at all"

 Dr. Edgar Spencer, Ph.D., 1995 



"I like to write code like  
other ppl like to tune their 
cars or 10kW hifi equipment..."


Christian Heimes, 2004


begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
email;internet:[EMAIL PROTECTED]
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] revised PLIP 113: CMF1.6 / GenericSetup

[whit]

Rob Miller wrote:


hi all,

i've revised PLIP 113 considerably.  it used to be proposing that the  
next release of Plone depend on CMF 2.0; it's now proposing instead  
that we depend on CMF 1.6, which will be very similar to CMF 1.5  
except that the GenericSetup stuff will be backported.  please take a  
look: http://members.plone.org/products/plone/roadmap/113


(whit, i rewrote this PLIP enough to where i listed myself as the  
proposer and you as the seconder, i hope this is okay with you.   
please feel free to remove yourself as a seconder if it's not.)


naw...I was just doing the needful.  but I'm happy to second

-w

--

| david "whit" morriss 
|
| contact :: http://public.xdi.org/=whit 

"If you don't know where you are,  
 you don't know anything at all"

 Dr. Edgar Spencer, Ph.D., 1995 



"I like to write code like  
other ppl like to tune their 
cars or 10kW hifi equipment..."


Christian Heimes, 2004


begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
email;internet:[EMAIL PROTECTED]
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] the end is nye

[whit]

alecm is getting cookies from my girlfriend...

-w

Alec Mitchell wrote:


On Monday 14 November 2005 11:23 am, Michel Pelletier wrote:
 


+1 on disolving the team.  I think it's a great idea and lots of other
folks would jump on board.

Maybe one person should stay on so that the next team doesn't have to
figure it all again.  I nominate Whit ;)
   



+1 from me on switching things up as well.  Though Whit has done a great job, 
I think that it is more useful and important to somewhat formally document 
the process so that the next team doesn't have to figure it out, rather than 
saddle up a likely already exhausted Whit for another ride. ;)


Alec
___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

 




--

| david "whit" morriss 
|
| contact :: http://public.xdi.org/=whit 

"If you don't know where you are,  
 you don't know anything at all"

 Dr. Edgar Spencer, Ph.D., 1995 



"I like to write code like  
other ppl like to tune their 
cars or 10kW hifi equipment..."


Christian Heimes, 2004


begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
email;internet:[EMAIL PROTECTED]
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] the end is nye

[whit morriss]

Michel Pelletier wrote:



+1 on disolving the team.  I think it's a great idea and lots of other 
folks would jump on board.


Maybe one person should stay on so that the next team doesn't have to 
figure it all again.  I nominate Whit ;)


-Michel


dude. my girlfriend is going kick your ass

hopefully everybody will stay involved.  I mean, I'll make bundles and 
lists 4eva.  I also think that alan is going to remain 
benevolent-pain-in-the-ass-for-life so we should just go ahead and 
formalize the position (BPITAFL) and expect the phone calls ;)



but voting really requires timezone sync and I'm not moving to europe 
for the summer of 2006 though it does sound appealing.  


-w

--

| david "whit" morriss 
|
| contact :: http://public.xdi.org/=whit 

"If you don't know where you are,  
 you don't know anything at all"

 Dr. Edgar Spencer, Ph.D., 1995 



"I like to write code like  
other ppl like to tune their 
cars or 10kW hifi equipment..."


Christian Heimes, 2004


begin:vcard
fn:david "whit" morriss
n:morriss;david "whit"
org:Independent
adr:;;2220 30th Ave S;Nashville;TN;37212;USA
email;internet:[EMAIL PROTECTED]
title:Freelance programmer
tel;cell:415-710-8975
note;quoted-printable:=0D=0A=
	IRC: irc.freenode.net : _whit_ / brcwhit=0D=0A=
	IM :: AIM: horkinpf=0D=0A=
	SCM :: SourceForge / svn.plone.org : brcwhit=0D=0A=
	
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

[Framework-Team] the end is nye

[whit morriss]

Being that primary purpose of the framework team is to review code, some 
short day after December 1 the plone 2.2 framework team becomes 
obsolete.   Or at least enters a time of transition.


being the bootstrap team, we get the honor of deciding what happens next 
and I'm going to make a proposal that should  sound pretty familar.


After December 1, we finish our code review and work with stefan to 
create a loose release plan (strengths, weakness, risks, how will these 
things be accomplished).This plan becomes our final report.  Then we 
choose a new leader for the framework team (I nominate stefan) who then 
picks the new framework team of people he wants to work with (ie people 
with whom he can easily teleconference).


I think it's important, especially for this first team, to bow out 
quickly into the ranks of the developers. 

1.  having considered the process from the bootstrap stages, we can best 
support it as developers.  After we indoctrinate the new team, there are 
automatically twice as many people invested this process and who can 
explain it to others.



2. we don't want our roles as a framework team member to adversely 
effect the development dynamic. and hopefully, all of us will being 
participating in the release.



3. and, we *really* don't want anyone to get the impression that the 
framework team is responsible for releases or development in the sense 
of cranking out code and fixing bugs.  that's work we do as 
developers.   disolving the 2.2 team immediately prevents any confusion.



4. Picking a new framework gets new people involved in the process at 
what I think is the right time.  Why? because this will be the downtime 
for code review and the best time to impart what we have learned so far. 


It also is the right time to start looking forward to 2.3.


5. It's alway good to purge the old regime.  we want the new team to 
feel free to adapt the process to work f
or them.  

Our pool is deep in talent but not so in numbers, so I imagine some of 
the same faces will appear again as the member of the framework moves 
East and West.   voting members are only a necessity because somebodies 
got to be responsible for making decisions.


-w

--

| david "whit" morriss 
|
| contact :: http://public.xdi.org/=whit 

"If you don't know where you are,  
 you don't know anything at all"

 Dr. Edgar Spencer, Ph.D., 1995 



"I like to write code like  
other ppl like to tune their 
cars or 10kW hifi equipment..."


Christian Heimes, 2004


begin:vcard
fn:david "whit" morriss
n:morriss;david "whit"
org:Independent
adr:;;2220 30th Ave S;Nashville;TN;37212;USA
email;internet:[EMAIL PROTECTED]
title:Freelance programmer
tel;cell:415-710-8975
note;quoted-printable:=0D=0A=
	IRC: irc.freenode.net : _whit_ / brcwhit=0D=0A=
	IM :: AIM: horkinpf=0D=0A=
	SCM :: SourceForge / svn.plone.org : brcwhit=0D=0A=
	
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

[Framework-Team] postpone phone call

[whit]

hey yall,

could we postpone this.  I'll be on plone framework in ten minutes.

-w

--

| david "whit" morriss 
|
| contact :: http://public.xdi.org/=whit 

"If you don't know where you are,  
 you don't know anything at all"

 Dr. Edgar Spencer, Ph.D., 1995 



"I like to write code like  
other ppl like to tune their 
cars or 10kW hifi equipment..."


Christian Heimes, 2004


begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
email;internet:[EMAIL PROTECTED]
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

[Framework-Team] phone chat / laundry list

[whit]

weekly meeting 30mins at 12:00 pm CST

agenda
-

- report from goldegg
- no new bundles
- cmf2.0 plip
   - Tres has written handlers for PAS
   - backward compatibility
- new development pages
- laundry list

laundry list aka the un-plip


We are going to start a wiki page for getting the needful done.  This is 
guided by plips and bundles but not restricted to it.   this is a fast 
and furious todo list that starts here.


1. what plips haven't been written that should be

2. what needs to be done for currently approved plips
   for Dec 20th alpha

3. what broken windows need to be fixed (where is the stack sucking, 
broken or lacking tests, poor structure, insane code, etc.)


4. low hanging fruit (optimization, use of CA, etc)


-w

--

| david "whit" morriss 
|
| contact :: http://public.xdi.org/=whit 

"If you don't know where you are,  
 you don't know anything at all"

 Dr. Edgar Spencer, Ph.D., 1995 



"I like to write code like  
other ppl like to tune their 
cars or 10kW hifi equipment..."


Christian Heimes, 2004


begin:vcard
fn:D. Whitfield  Morriss
n:Morriss;D. Whitfield 
email;internet:[EMAIL PROTECTED]
tel;home:615 292-9142
tel;cell:415 710-8975
x-mozilla-html:FALSE
version:2.1
end:vcard

___
Framework-Team mailing list
[EMAIL PROTECTED]
http://lists.plone.org/mailman/listinfo/framework-team