Re: [Zope-dev] Moving forward on Zope 2.6
Jim Penny [EMAIL PROTECTED] wrote: [...] I needed a generalization of this scheme (and so ended up writing my own User Folder). We manufacture parts which are controlled by second parties, but bought primarily by third parties. I will call these parties Manufacturer, Brand Owners, and Contractors. I now have two kinds of administrators, and two kinds of users. There are unrestricted administrators and users. Since this really is enforced only at the user folder level (normal zope machinery is used elsewhere), a quick description is that an unrestricted administrator may create, modify or destroy any user or Brand Owner Name, and may associate any list of Brand owner names with any user. Any unrestricted user has a flag designating him as such and it is expected that application code check the flag and permit access to the contents held for Brand Owners. Restricted Administrators may create new users, modify users, or delete (some) users. However, any user they create may have only a subset of their brand owner name list (and their normal zope permissions). They may remove any of their brand names from a user that has one or more of the brand names under their control. They may delete users that have brand names only under their control. They may also create other administrators, subject to the subset restictions. Restricted Users have a brand list associated with them. Application logic can use this brand list to filter content. The restricted administrator is a big deal to us. If this takes off, we will not be able to properly control the set of Restricted Users (at Brand Owners and Contractors). Failure to do so could lead to legal exposure, so by creating Restricted Administrators who are Brand Owners, the contrl (and thus most of the legal exposure) can be shifted back to the Brand Owner. This screams of ACLs for user management... I'm having the need too, in the context of CMF. I ended up writing an additional service (portal_directory) that has a complex set of ACLs to mediate access to the user folder. Some code will be released soon. Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 10 http://nuxeo.com mailto:[EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Flush memory from product
Hello zopers, I'm writing a product with a relational database mapping. When I launch loading procedures, the product creates ~ 5 instances. I regulary do a get_transaction().commit(), but memory still increase constantly (more than 300 megs for python processes) How can I flush memory ? Tested with : gnu/linux debian potato, zope 2.3.3 gnu/linux debian woody, zope 2.5.0 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Moving forward on Zope 2.6
From: Jim Penny [EMAIL PROTECTED] I now have two kinds of administrators, and two kinds of users. An interesting case. If I understand it correctly, with our workgroups scheme,the restricted administrators would have administration rights on a workgroup. They would then be able to create users and add them to the workgroup they manage, but they wouldn't be able to give the users any priviligies outside the workgroup, and hence the new users priviligies would be limited to whatever priviligies they can get through the workgroup. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Moving forward on Zope 2.6
I'm trying to wrap my mind around what you call workgroups. By the way, have you reviewed the use cases for workgroups that I put in http://www.zope.org/Members/nuxeo/Products/NuxUserGroups/README.txt ? Lennart Regebro [EMAIL PROTECTED] wrote: [...] With normal grouping, you typically have one group per department, and give that department access to a couple of parts of the database. Then you have a group of the Bosses that have more access. But usually this means that all the Bosses have Boss access everywhere, which is not necessarily what you want. No no no ! With NUG the Roles added to a group are still added at the local role level, which means that the 'bosses' group only has a Boss role where you want it. Besides in the current NUG I don't yet have a way to assign a global Role to a group (this can be added later anyway, the current model is all that we needed, and the implementation is flexible enough to permit it later). I really think that my model can be used for what you do. So, even if it is very tempting to let Florent implement the local roles blacklist instead of doing it ourselves :-), I'd rather wait for workgroups than standard groups. In any case Johan and me would be very happy to help Florent and the others at Nuxeo implement it groups and blacklists. Thanks. But I insist that my groups are nearly the same as your workgroups. Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 10 http://nuxeo.com mailto:[EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Flush memory from product
de ZORZI Frederic wrote: Hello zopers, I'm writing a product with a relational database mapping. When I launch loading procedures, the product creates ~ 5 instances. I regulary do a get_transaction().commit(), but memory still increase constantly (more than 300 megs for python processes) How can I flush memory ? Tested with : gnu/linux debian potato, zope 2.3.3 gnu/linux debian woody, zope 2.5.0 Oops; in fact, after the loading process, even with flush cache from the control panel, python process still take 320M of memory (20M after zope restart). Any idea ? ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Moving forward on Zope 2.6
From: Florent Guillaume [EMAIL PROTECTED] No no no ! With NUG the Roles added to a group are still added at the local role level, which means that the 'bosses' group only has a Boss role where you want it. Yes, of course. But what I was aiming at is that all the Bosses have Boss right at all the places where the Boss group have rights. There is no way to differentiate within one group. I really think that my model can be used for what you do. Sure it can. What you have to do is that for each role that you want within a workgroup you will have to create one group. So if you have ten departments, and you have five roles within these departments (f ex authors, reviewers, HR, CR and Bosses), you just create 50 different groups, one group for each department and role, and assign the permission for each of these fifty roles at the correct locations in the hierarchy. In a nightmare scenario, each department should have exclusive access to say 2 areas, and access to one shared area. This means that you need to do 50*3 = 150 group to roles mappings. So yes, you can. It's just more work. Just as if this was done without any groups at all, you would have to add each user to the local roles to each place. Say 15 users in each department times ten departments is 150 users times 3 locations gives you 450 separate assignments. No fun. With workgroups you create ten workgroups. Within each workgrup you assign users to their respective roles. You then add the workgroups to the correct places in the hierarchy. It also opens for the possibility to assign workgroup managers that can create users and add them to their groups without having any other manager rights (although this could be added later to make it easier to implement). By the way, have you reviewed the use cases for workgroups that I put in http://www.zope.org/Members/nuxeo/Products/NuxUserGroups/README.txt ? Now I have. :-) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Moving forward on Zope 2.6
On Wed, Mar 20, 2002 at 07:01:13PM +0100, Lennart Regebro wrote: From: Jim Penny [EMAIL PROTECTED] I now have two kinds of administrators, and two kinds of users. An interesting case. If I understand it correctly, with our workgroups scheme,the restricted administrators would have administration rights on a workgroup. They would then be able to create users and add them to the workgroup they manage, but they wouldn't be able to give the users any priviligies outside the workgroup, and hence the new users priviligies would be limited to whatever priviligies they can get through the workgroup. Right, although they may have adminstration priveleges on a set of workgroups. To give a motivation, consider a large company that has parallel design groups. The groups are intentionally kept in the dark about the other groups' work. Some companies do this to get a variety of choices to base the final decision on. Just to label them, call them Green, Blue, and Red teams. In this case, I might delegate an administrator who has authority over all of these teams, i.e, the administrator can (partially) control users or other administrators who have a subset of (Green, Red, and Blue) in their group list. The administrator, being a busy fellow himself, might create a Red administrator, who can (partially) control users or other adminstrators that have Red in their group list. Now, I am not really deep into modifying Zope core code at this point. The list of acceptable groups is available for any given user. The application programmer handles authorization and presentation. We have to have this for both reasons of scale and delegation of authority. Some, even many, of the design teams themselves use sub-contractors. We have no way of knowing the contractor's day-to-day relationships with the groups, and prefer not to know. Also, we are in a somewhat incestuous industry, and people move from company to company. While they obviously have what is in their head at the time of the move, we do not wish to give them knowledge of future plans. There are interesting policy decisions to make. Should an administrator be allowed to grant workgroup access to a pre-existing user? Can an administrator change a pre-existing user into an administrator? What does delete mean if the use has workgroups that the administrator does not control? Can the administrator see what workgroups the user has? Jim ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Moving forward on Zope 2.6
Lennart Regebro [EMAIL PROTECTED] wrote: With workgroups you create ten workgroups. Within each workgrup you assign users to their respective roles. You then add the workgroups to the correct places in the hierarchy. It also opens for the possibility to assign workgroup managers that can create users and add them to their groups without having any other manager rights (although this could be added later to make it easier to implement). Okay now I understand. It's indeed another form of indirect management of local roles. In getRolesInContext you'd have to have examine __ac_local_workgroups__, containing the list of workgroup ids, and to know what user-role mapping a workgroup has you'd have to consult the place where the workgroup definitions are stored, probably the acl_user of the user we're currently looking at. Then it's simply :-) a matter of user interface. There's also the question of what permissions are needed to modify a workgroup of course. Does this match what you want ? Looks quite feasible to me, and I think it can be done pretty independantly of the user groups I propose. Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 10 http://nuxeo.com mailto:[EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Next steps on Zope 2.6 plan
Hi all, As talked about last week, I've updated the proposed features document for Zope 2.6: http://dev.zope.org/Wikis/DevSite/Projects/Zope2.6/ProposedFeatures ...to cut out those proposals without volunteers. Now comes the hard part :^) There are quite a few proposals there. The current list is still a laundry list - it reflects every idea that someone had and volunteered for without any consideration of whether the proposals are good / bad / indifferent. Now we need to do a quality chop to turn the laundry list into an actual project plan consisting of only things that: 1 Have volunteers committed to producing the code AND associated documentation 2 Are generally agreed to be good ideas, for some definition of generally and good :) 3 Can realistically be completed (code and docs) by the May 1 target we are setting for 2.6 alpha 1. Getting from laundry list to project plan is made a bit harder this time around because this is the first really community-driven release, and we don't have any real process in place for getting there :( I think that we have #1 above under control, and #3 does not bother me that much, but #2 is a tough cookie. Right now, the laundry list includes some competing proposals (things that solve the same or similar problems in different ways), as well as some better XXX proposals that compete with things already in the core and some pretty big overhaul XXX proposals with wide ranging non-trivial impacts on documentation, packaging and other non-software concerns. Somehow we need to get to resolution on these things. I know that realistically we'll be winging it for 2.6 (there's no way that we could get any sort of well-thought-out generally agreed upon process in place in time). But while we're winging it, I'd like for us to be starting to think about these things and putting pieces in place as we're able. One suggestion Casey had was to start to codify a set of rules that features have to abide by to be considered for inclusion. Some examples here would be: - A feature that is a better X than X (where X is a feature or component already in Zope), has a much higher bar to jump over since it will almost never be worth the user confusion and extra documenation burden to add another component that does almost (but not quite!) the same thing as an existing builtin component. For example, if you have a better Folder implementation, the right approach is to add your betterness to the current builtin Folder, because Zope is not going to ship with two kinds of Folder (with the associated two sets of docs, etc.) without a very, very good reason *. * Exhibit A for multiple similar objects causing confusion: DTML Document and DTML Method. - A feature release should never contain more than one blow-it- up-and-redo-it type project (such as radical changes to key parts of packaging or infrastructure). For example, it would probably be a bad idea to totally redo the ZODB, packaging and installation and the security system all in one release (unless it is a major release like Zope2 - Zope3). The aggregate impact in terms of obsoleting existing knowledge and documentation is too great to do many of these at once. It takes time for users and developers to catch up after something major is refactored, and we need to keep this in mind. - Features or components added to the Zope core should address a clear and generally agreed-upon need. Otherwise, accumulation of components over time will become a significant support burden for the zope maintainers. - Features that affect the security system face a higher analysis, design and documentation burden :^) I'm sure there are many other good guidelines, but you get the idea. Having a set of ground rules that everyone agrees on will make it easier to keep focused on arguing edge cases (instead of every detail) when it's time to define a release. Thoughts? I'll volunteer to maintain the guidelines document on dev.zope.org if folks can send their guideline suggestions. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Structured text issues (again?)
How extensively is STX actually used? I've been looking at it myself
recently, and the whole system seem rather simplistic to me in how it
parses the text. I'm talking specifically of the STX version currently
standard in Zope 2.5 (and 2.4 I think), which I believe is STXNG; I
haven't gone back to look at how the previous version worked. I have
looked at some of the past mailing list posts on this topic, and
although it is clear that things have been improved a lot, I am
surprised that not more was done so far.
I explain the problems I see next, followed by a proposed algorithm
change and some rough code to make things better. I'm doing this now
for two reasons:
First, if I'm missing something important wrt the reasons things are as
they are, I'm obviously interested to know before I spend any more time
on this.
Second, maybe these proposed changes are actually a step in the right
direction, or might help someone else do what they need, so I'm
providing the code of what I've done so far, as is, in case it can be of
help (I am unlikely to have the time to come up with a polished set of
changes myself any time soon). Or I guess what I'm saying is (wink wink
nudge nudge): If someone else feels like picking up on this and
finishing it up so I don't have to, feel free ;-)
The biggest problem I see is that the various text types are given
somewhat arbitrary preference from the order in which they appear in the
text_types list. Given that the patterns in text_types are looked at in
order, with the first match breaking the raw string in half, then any
other structure that would have spanned a larger part of the string but
is lower in the text_types list is effectively ignored.
For example, since doc_strong is currently listed before doc_emphasize,
*emphasized **strong** emphasized* does enclose strong in strong
tags, but completely ignores the single *'s because they do not form a
matching pair (because the parsing of **strong** breaks the rest in two
separate strings *emphasized and emphasized*).
Following the same reasoning, I assumed that **strong *emphasized*
strong** would work better, but it did not! This time, it's because the
regexp for doc_strong is rather simplistic, as it does not allow ANY '*'
within (strongem_punc), whereas it should only care to not allow the
specific pattern '**' inside. In this case, wouldn't the easiest
solution be to simply use the non-greedy matching? i.e replace:
r'\*\*([%s%s%s\s]+?)\*\*' % (letters, digits, strongem_punc)
with:
r'\*\*(.*?)\*\*'
or actually better:
r'(?!\*\*\*)\*\*(?!\*\*\*)(.*?)(?!\*\*\*)\*\*(?!\*\*\*)'
I think the last pattern is best because it will not recognize the
middle as anything in **this: does not matter**, as I think
should normally be expected. BTW, I make no claim that the regexp above
is either the most elegant or the most efficient; this is the first one
I came up with that did what I wanted ;-)
Now, back to the problem with the ordered nature of text_types (the
reason *emphasized **strong** emphasized* does not work as expected).
Besides the extra computing required, any reason why the structures with
the largest span shouldn't be recognized first, regardless of the order
of text_types? I.E. what I propose is to go through all the text_types,
collecting the matching patterns, and only once this is done choose the
one with the largest span. Then proceed recursively with the enclosed
text until no pattern matches. This permits to succeed in quoting
structured text patterns: '**not bold**', and bolding quoted text: **
some text 'this is quoted' **. With the current implementation, none
of those work, i.e. '**not bold**' ends up being bolded and not
quoted, and ** some text 'this is quoted' ** is a total mess because
the text in is interpreted as SGML instead of being quoted as
requested.
The changes I have made so far (all in DocumentClass.py):
The simplest are the few regexp changes I have made for doc_strong,
doc_emphasize, and doc_literal (actually doc_literal probably doesn't
matter (I used the pattern proposed by someone else on this list to make
the quoting more obvious), but the changes to doc_strong and
doc_emphasize are required to make my other changes work).
doc_strong becomes:
r'(?!\*\*\*)\*\*(?!\*\*\*)(.*?)(?!\*\*\*)\*\*(?!\*\*\*)'
doc_emphasize becomes:
r'(?!\*\*)\*(?!\*\*)(.*?)(?!\*\*)\*(?!\*\*)'
and doc_literal becomes:
r(\W+|^)``([%s%s%s\s]+)''([%s]+|$) % (letters, digits, literal_punc,
phrase_delimiters)
The big changes are to the parse and color_text methods.
Parse now only returns the first match found of a type rather than all
of them, and it returns the start and end indices of the match so that
the span size can be computed in color_text:
def parse(self, raw_string, text_type,
type=type, st=type(''), lt=type([])):
Parse accepts a raw_string, an expr to test the raw_string,
and the raw_string's subparagraphs.
Parse
Re: [Zope-dev] Structured text issues (again?)
On Thu, 21 Mar 2002 08:40, [EMAIL PROTECTED] wrote: How extensively is STX actually used? I've been looking at it myself recently, and the whole system seem rather simplistic to me in how it parses the text. I'm talking specifically of the STX version currently standard in Zope 2.5 (and 2.4 I think), which I believe is STXNG; [snip] I explain the problems I see next, followed by a proposed algorithm change and some rough code to make things better. Please also see the ReStructureText effort which addresses a lot of the problems that STXNG is perceived to have. It's really very nice, and one of these days I hope to get it wrapped in a Zope Product. http://structuredtext.sf.net/ Note specifically: http://structuredtext.sourceforge.net/spec/problems.txt If something you see as being a problem in STXNG isn't addressed there, I'm sure the author of ReST would love to hear about it! Richard ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Structured text issues (again?)
I wasn't aware of that effort, thanks for pointing it out. I was only tinkering so of course that project is a much more complete solution than what I was envisioning. Went through problems.txt and more rapidly throught the specs, and I liked what I saw. There is a formal statement on the handling of nested inline markup, but I wonder again if it is not overly restrictive: Inline markup delimiter characters are used for multiple constructs, so to avoid ambiguity there must be a specific recognition order for each character. The inline markup recognition order is as follows: - Asterisks: `Strong emphasis`_ (**) is recognized before emphasis_ (*). I don't see why these two markups couldn't be recognized independently and unambiguously (well, mostly). Anyway, is discussion of that particular project OT for the Zope list? Is there any consideration being given to ultimately migrating Zope's core structured text to that implementation once it is sufficiently advanced? One problem I guess is that there are enough differences between the implementations to break existing structured text previously produced by Zope users. Cheers, Jean Richard Jones wrote: On Thu, 21 Mar 2002 08:40, [EMAIL PROTECTED] wrote: How extensively is STX actually used? I've been looking at it myself recently, and the whole system seem rather simplistic to me in how it parses the text. I'm talking specifically of the STX version currently standard in Zope 2.5 (and 2.4 I think), which I believe is STXNG; [snip] I explain the problems I see next, followed by a proposed algorithm change and some rough code to make things better. Please also see the ReStructureText effort which addresses a lot of the problems that STXNG is perceived to have. It's really very nice, and one of these days I hope to get it wrapped in a Zope Product. http://structuredtext.sf.net/ Note specifically: http://structuredtext.sourceforge.net/spec/problems.txt If something you see as being a problem in STXNG isn't addressed there, I'm sure the author of ReST would love to hear about it! Richard ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] PageTemplate Internet Explorer error
Hi,
I have the latest PageTemplates, ZTUtils, and TAL installed on Zope 2.4.3
with python 2.1.1 on Linux.
Whenever I try to create or edit a PageTemplate using IE5.5 or IE6 on
windows I get the following error. It works fine however when I use
Netscape or Mozilla on windows or linux.
I have seen some other emails about this error, but none seemed to suggest
that the problem was ever solved. Is somebody working on this, or has
somebody found a solution?
terry kerr
Site Error
An error was encountered while publishing this resource.
Error Type: Undefined
Error Value: manage_page_header not found in here/manage_page_header
Troubleshooting Suggestions
The URL may be incorrect.
The parameters passed to this resource may be incorrect.
A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to the HTML
source for this page.
If the error persists please contact the site maintainer. Thank you for
your patience.
Traceback (innermost last):
File /home/zope/Zope/lib/python/ZPublisher/Publish.py, line 223, in
publish_module
File /home/zope/Zope/lib/python/ZPublisher/Publish.py, line 187, in
publish
File /home/zope/Zope/lib/python/Zope/__init__.py, line 226, in
zpublisher_exception_hook
File /home/zope/Zope/lib/python/ZPublisher/Publish.py, line 171, in
publish
File /home/zope/Zope/lib/python/ZPublisher/mapply.py, line 160, in mapply
(Object: ptAdd)
File /home/zope/Zope/lib/python/ZPublisher/Publish.py, line 112, in
call_object
(Object: ptAdd)
File /home/zope/Zope/lib/python/Shared/DC/Scripts/Bindings.py, line 324,
in __call__
(Object: ptAdd)
File /home/zope/Zope/lib/python/Shared/DC/Scripts/Bindings.py, line 354,
in _bindAndExec
(Object: ptAdd)
File /home/zope/Zope/lib/python/Products/PageTemplates/PageTemplateFile.py,
line 163, in _exec
(Object: ptAdd)
File /home/zope/Zope/lib/python/Products/PageTemplates/PageTemplate.py,
line 156, in pt_render
(Object: ptAdd)
(Info: {'container': __FactoryDispatcher__ instance at 90c56d8,
'here': __FactoryDispatcher__ instance at 90c56d8,
'modules': Products.PageTemplates.ZRPythonExpr._SecureModuleImporter
instance at 0x95dabdc,
'nothing': None,
'options': {'args': ()},
'request':
h3form/h3table/tableh3cookies/h3table/tableh3other/h3ta
bletr valign=top
align=leftthAUTHENTICATION_PATH/thtd''/td/trtr valign=top
align=leftthURL3/thtd'http://orgazmo.adroit:8080'/td/trtr
valign=top
align=leftthURL0/thtd'http://orgazmo.adroit:8080/manage_addProduct/
PageTemplates/ptAdd'/td/trtr valign=top
align=leftthURL1/thtd'http://orgazmo.adroit:8080/manage_addProduct/
PageTemplates'/td/trtr valign=top
align=leftthBASE3/thtd'http://orgazmo.adroit:8080/manage_addProduct
/PageTemplates'/td/trtr valign=top
align=leftthURL2/thtd'http://orgazmo.adroit:8080/manage_addProduct'
/td/trtr valign=top
align=leftthBASE1/thtd'http://orgazmo.adroit:8080'/td/trtr
valign=top align=leftthtraverse_subpath/thtd[]/td/trtr
valign=top
align=leftthSERVER_URL/thtd'http://orgazmo.adroit:8080'/td/trt
r valign=top align=leftthPUBLISHED/thtdlt;PageTemplateFile
instance at 91b4888gt;/td/trtr valign=top
align=leftthURL/thtd'http://orgazmo.adroit:8080/manage_addProduct/P
ageTemplates/ptAdd'/td/trtr valign=top
align=leftthAUTHENTICATED_USER/thtdAnonymous User/td/trtr
valign=top
align=leftthBASE2/thtd'http://orgazmo.adroit:8080/manage_addProduct
'/td/trtr valign=top
align=leftthTraversalRequestNameStack/thtd[]/td/trtr
valign=top
align=leftthBASE0/thtd'http://orgazmo.adroit:8080'/td/trtr
valign=top
align=leftthBASE4/thtd'http://orgazmo.adroit:8080/manage_addProduct
/PageTemplates/ptAdd'/td/trtr valign=top
align=leftthURL0/thtdhttp://orgazmo.adroit:8080/manage_addProduct/P
ageTemplates/ptAdd/td/trtr valign=top
align=leftthURL1/thtdhttp://orgazmo.adroit:8080/manage_addProduct/P
ageTemplates/td/trtr valign=top
align=leftthURL2/thtdhttp://orgazmo.adroit:8080/manage_addProduct/
td/trtr valign=top
align=leftthURL3/thtdhttp://orgazmo.adroit:8080/td/trtr
valign=top
align=leftthBASE0/thtdhttp://orgazmo.adroit:8080/td/trtr
valign=top
align=leftthBASE1/thtdhttp://orgazmo.adroit:8080/td/trtr
valign=top
align=leftthBASE2/thtdhttp://orgazmo.adroit:8080/manage_addProduct
/td/trtr valign=top
align=leftthBASE3/thtdhttp://orgazmo.adroit:8080/manage_addProduct/
PageTemplates/td/trtr valign=top
align=leftthBASE4/thtdhttp://orgazmo.adroit:8080/manage_addProduct/
PageTemplates/ptAdd/td/tr/tableh3environ/h3tabletr
valign=top align=leftthHTTP_ACCEPT_ENCODING/thtd'gzip,
deflate'/td/trtr valign=top
align=leftthchannel.creation_time/thtd1016684537/td/trtr
valign=top
align=leftthSERVER_PROTOCOL/thtd'HTTP/1.1'/td/trtr
valign=top align=leftthSERVER_PORT/thtd'8080'/td/trtr
valign=top
align=leftthPATH_INFO/thtd'/manage_addProduct/PageTemplates/ptAdd'
/td/trtr valign=top
