You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jspwiki.apache.org by Terry Steichen <te...@net-frame.com> on 2008/05/07 00:38:21 UTC
Other 2.6.2 changes
I noticed with 2.6.2 that when a user changes their fullname, for all
the groups in which they are a member, their member identifier is
changed from the logname (which I normally use as the identifier) to the
new fullname. Is that the intended behavior?
Second, when the above change occurs, JSPWiki does not appear to
recognize that user's membership in the appropriate groups until that
user logs out and then logs back in. Is that intended behavior?
Third, when typing '[' followed by some characters into the editor, I
get a continuous set of "TypeError: el has no properties" alert boxes.
What does this mean? More importantly, how do I turn it off?
Re: Other 2.6.2 changes
Posted by Murray Altheim <mu...@altheim.com>.
Terry Steichen wrote:
> I noticed with 2.6.2
[...]
> Third, when typing '[' followed by some characters into the editor, I
> get a continuous set of "TypeError: el has no properties" alert boxes.
> What does this mean? More importantly, how do I turn it off?
I can't speak to the first two questions, but the third is a behaviour
that, when working, pops up a menu of matching (currently available) wiki
page names, I'm assuming so that you can select one from the list as a
shortcut. For me, on Firefox 2.0.0.14 on Ubuntu 7.10, the menu pops up
but selecting from it via the mouse has no effect. For you, you're
apparently getting a broken popup menu, perhaps due to localization?
Not sure how much help this is -- whoever is the expert on the i18n
features of JSPWiki might be able to lend a hand, though I think this
is likely mostly related to JavaScript. (e.g., as a test, turning off
JavaScript likely halts the error messages)
Murray
...........................................................................
Murray Altheim <murray07 at altheim.com> === = =
http://www.altheim.com/murray/ = = ===
SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk = = = =
Boundless wind and moon - the eye within eyes,
Inexhaustible heaven and earth - the light beyond light,
The willow dark, the flower bright - ten thousand houses,
Knock at any door - there's one who will respond.
-- The Blue Cliff Record
Re: Other 2.6.2 changes
Posted by Dirk Frederickx <di...@gmail.com>.
To disable the function, just remove the onkeyp handler in your plain.jsp.
The error you get is coming from the getSuggesitons function, which is
located in jspwik-edit.js
>>>
<textarea id="editorarea" name="<%=EditorManager.REQ_EDITEDTEXT%>"
class="editor"
onkeyup="getSuggestions(this.id)" >>>>> remove this line
onclick="setCursorPos(this.id)"
onchange="setCursorPos(this.id)"
>>>
dirk
On Wed, May 7, 2008 at 9:20 PM, Terry Steichen <te...@net-frame.com> wrote:
> Dirk,
>
> I'm using Firefox 1.5.0.12 on Fedora 6. I'm running two JSPWiki 2.6.2
> instances: (1) a "plain jane" install, and (2) an install to which I've
> added my custom modules. The former works fine, but the phenomena I
> described happens on the customized install. The thing is that my
> customization is 99% additive; the edits I do to the JSPWiki modules are
> very simple, mostly commenting out features I don't offer. IOW, the
> customized version starts with a "plain jane" and then the custom
> modules are added. So, AFAIK, all the scripts and such are present.
>
> No, there is no additional information available in the alert. And
> again, once I type a left bracket ('['), then every letter I type after
> that causes the alert to pop up. If I type the characters, and then,
> when I'm finished, add the brackets, it seems to work (no popups). I
> would imagine it has something to do with the "Smart typing pairs", but
> don't know. (That option is not checked, however.)
>
> If what's going on isn't obvious, then I don't expect you to help me
> debug. Maybe, in that case, you could point me to the part of the JS
> code that does this, and I'll disable it (or possibly fix it) myself.
>
> Terry
>
>
>
> On Wed, 2008-05-07 at 20:35 +0200, Dirk Frederickx wrote:
>
> > Terry,
> >
> >
> > Plse provide some more info. Which browser are you using ?
> > Does the errror message has a js line-number or something ?
> >
> >
> > So far, the suggestbox seems to work fine on the 2.6.2. stable version.
> >
> >
> > dirk
> >
> > On Wed, May 7, 2008 at 12:39 PM, Terry Steichen <te...@net-frame.com> wrote:
> > >
> > > On Wed, 2008-05-07 at 08:38 +0300, Janne Jalkanen wrote:
> > >
> > > > > Third, when typing '[' followed by some characters into the editor, I
> > > > > get a continuous set of "TypeError: el has no properties" alert
> > > > > boxes.
> > > > > What does this mean? More importantly, how do I turn it off?
> > > >
> > > > Yes, it's a Javascript error. You have probably changed the editor
> > > > in such a way that the JS code responsible for the auto-link matcher
> > > > does not find the editor textarea.
> > >
> > > Well, AFAIK, I'm using the standard plain editor (per your earlier
> > > suggestion, I did away with my customization to make the SpamFilter work
> > > properly). Once I trick the editor into taking what I'm typing (by
> > > putting the brackets in after I've finished the text, and deleting the
> > > second one it inserts), the resulting text file works fine, links and
> > > all. It only seems to be a problem when I'm trying to type in links
> > > (with brackets). But it's a real pain to go through all that. Do you
> > > have any idea of just how I can disable that "feature?" [Dirk?]
> > >
> > >
>
Re: Other 2.6.2 changes
Posted by Terry Steichen <te...@net-frame.com>.
Dirk,
I'm using Firefox 1.5.0.12 on Fedora 6. I'm running two JSPWiki 2.6.2
instances: (1) a "plain jane" install, and (2) an install to which I've
added my custom modules. The former works fine, but the phenomena I
described happens on the customized install. The thing is that my
customization is 99% additive; the edits I do to the JSPWiki modules are
very simple, mostly commenting out features I don't offer. IOW, the
customized version starts with a "plain jane" and then the custom
modules are added. So, AFAIK, all the scripts and such are present.
No, there is no additional information available in the alert. And
again, once I type a left bracket ('['), then every letter I type after
that causes the alert to pop up. If I type the characters, and then,
when I'm finished, add the brackets, it seems to work (no popups). I
would imagine it has something to do with the "Smart typing pairs", but
don't know. (That option is not checked, however.)
If what's going on isn't obvious, then I don't expect you to help me
debug. Maybe, in that case, you could point me to the part of the JS
code that does this, and I'll disable it (or possibly fix it) myself.
Terry
On Wed, 2008-05-07 at 20:35 +0200, Dirk Frederickx wrote:
> Terry,
>
>
> Plse provide some more info. Which browser are you using ?
> Does the errror message has a js line-number or something ?
>
>
> So far, the suggestbox seems to work fine on the 2.6.2. stable version.
>
>
> dirk
>
> On Wed, May 7, 2008 at 12:39 PM, Terry Steichen <te...@net-frame.com> wrote:
> >
> > On Wed, 2008-05-07 at 08:38 +0300, Janne Jalkanen wrote:
> >
> > > > Third, when typing '[' followed by some characters into the editor, I
> > > > get a continuous set of "TypeError: el has no properties" alert
> > > > boxes.
> > > > What does this mean? More importantly, how do I turn it off?
> > >
> > > Yes, it's a Javascript error. You have probably changed the editor
> > > in such a way that the JS code responsible for the auto-link matcher
> > > does not find the editor textarea.
> >
> > Well, AFAIK, I'm using the standard plain editor (per your earlier
> > suggestion, I did away with my customization to make the SpamFilter work
> > properly). Once I trick the editor into taking what I'm typing (by
> > putting the brackets in after I've finished the text, and deleting the
> > second one it inserts), the resulting text file works fine, links and
> > all. It only seems to be a problem when I'm trying to type in links
> > (with brackets). But it's a real pain to go through all that. Do you
> > have any idea of just how I can disable that "feature?" [Dirk?]
> >
> >
Re: Other 2.6.2 changes
Posted by Dirk Frederickx <di...@gmail.com>.
Terry,
Plse provide some more info. Which browser are you using ?
Does the errror message has a js line-number or something ?
So far, the suggestbox seems to work fine on the 2.6.2. stable version.
dirk
On Wed, May 7, 2008 at 12:39 PM, Terry Steichen <te...@net-frame.com> wrote:
>
> On Wed, 2008-05-07 at 08:38 +0300, Janne Jalkanen wrote:
>
> > > Third, when typing '[' followed by some characters into the editor, I
> > > get a continuous set of "TypeError: el has no properties" alert
> > > boxes.
> > > What does this mean? More importantly, how do I turn it off?
> >
> > Yes, it's a Javascript error. You have probably changed the editor
> > in such a way that the JS code responsible for the auto-link matcher
> > does not find the editor textarea.
>
> Well, AFAIK, I'm using the standard plain editor (per your earlier
> suggestion, I did away with my customization to make the SpamFilter work
> properly). Once I trick the editor into taking what I'm typing (by
> putting the brackets in after I've finished the text, and deleting the
> second one it inserts), the resulting text file works fine, links and
> all. It only seems to be a problem when I'm trying to type in links
> (with brackets). But it's a real pain to go through all that. Do you
> have any idea of just how I can disable that "feature?" [Dirk?]
>
>
Re: Other 2.6.2 changes
Posted by Terry Steichen <te...@net-frame.com>.
On Wed, 2008-05-07 at 08:38 +0300, Janne Jalkanen wrote:
> > Third, when typing '[' followed by some characters into the editor, I
> > get a continuous set of "TypeError: el has no properties" alert
> > boxes.
> > What does this mean? More importantly, how do I turn it off?
>
> Yes, it's a Javascript error. You have probably changed the editor
> in such a way that the JS code responsible for the auto-link matcher
> does not find the editor textarea.
Well, AFAIK, I'm using the standard plain editor (per your earlier
suggestion, I did away with my customization to make the SpamFilter work
properly). Once I trick the editor into taking what I'm typing (by
putting the brackets in after I've finished the text, and deleting the
second one it inserts), the resulting text file works fine, links and
all. It only seems to be a problem when I'm trying to type in links
(with brackets). But it's a real pain to go through all that. Do you
have any idea of just how I can disable that "feature?" [Dirk?]
Re: Other 2.6.2 changes
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
> Third, when typing '[' followed by some characters into the editor, I
> get a continuous set of "TypeError: el has no properties" alert
> boxes.
> What does this mean? More importantly, how do I turn it off?
Yes, it's a Javascript error. You have probably changed the editor
in such a way that the JS code responsible for the auto-link matcher
does not find the editor textarea.
/Janne
Re: Higher level project documentation, Was: Re: Other 2.6.2 changes
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
> Aren't there any tools which could analyze a code base and generate a
> project map / graphical class overview with dependencies a.s.o.?
Yes, there are, but these are in general useless, since they don't
really describe how the software works. Process diagrams and
tutorials are far more useful.
> Well I think, the big picture documentation can only be done by people
> who at least have enough overview on the project and its history.
True, but we still need someone who is willing to take overall
responsibility of the documentation and find the bits that need to be
documented. Also clean it up once someone writes some documentation,
and makes sure it is organized well and is up to date. I'm happy to
contribute when someone says that "this bit here, that needs
contribution from YOU since you understand it", but I can't take on
the entire project management of the documentation, too...
/Janne
Higher level project documentation, Was: Re: Other 2.6.2 changes
Posted by Florian Holeczek <fl...@holeczek.de>.
Hi there,
> Yes, I can certainly see what the issue here is - we are lacking
> some "big picture" documentation. The Javadocs are great if you know
> what you are doing, but if you don't know what the feature is and
> how it fits in the JSPWiki architecture, it's not that clear. HOWTOs
> and tutorials would be great, too.
that's the essence!
Aren't there any tools which could analyze a code base and generate a
project map / graphical class overview with dependencies a.s.o.?
> However, I can't stress enough the fact that this is a collaborative
> project, and as such, we *need* more people who can write concise
> documentation, howtos, architecture diagrams, etc. This beast is too
> big for any single person to ride anymore, so please do help us :-).
Well I think, the big picture documentation can only be done by people
who at least have enough overview on the project and its history.
Since the project is growing more and more, this should be done very
soon...
* before the situation gets worse, and it will.
* because the larger the project becomes, the more important this kind
of documentation will be for new developers and also for the project
lead to plan the future of the project.
Regards,
Florian
Re: Other 2.6.2 changes
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
Yes, I can certainly see what the issue here is - we are lacking some
"big picture" documentation. The Javadocs are great if you know what
you are doing, but if you don't know what the feature is and how it
fits in the JSPWiki architecture, it's not that clear. HOWTOs and
tutorials would be great, too.
And, since things are changing between major versions, it's not very
easy to keep track of all that stuff either. I know, I still don't
know all the things that the AAA subsystem is doing - neither can I
claim to understand the workflow system very well. I tried to make
SpamFilter to use it but forgot about it pretty soon, since I could
never get it to work they way I thought it was supposed to work...
However, I can't stress enough the fact that this is a collaborative
project, and as such, we *need* more people who can write concise
documentation, howtos, architecture diagrams, etc. This beast is too
big for any single person to ride anymore, so please do help us :-).
As much as we would like, we can't do *everything*. Code we can do;
javadocs we can write; but we would need people who would be willing
to sort of take the "documentation management" responsibility. For
example, see what needs to be documented, and then find volunteers,
see how much they're willing to do, and then simply divide up the job
and make sure that people are doing it.
Anybody?
(Yeah, our Javadocs are getting a lot better. Only 900 missing
@params to document or something... ;-)
(And don't worry Terry, you aren't saying anything I haven't cursed
under my breath already... But though Andrew is right: we *are*
easier to patch than many other OSS projects. Though patching them
is never easy, because we can change everything from under you,
unless you manage to get the patch approved and into the codebase...)
/Janne
On 7 May 2008, at 19:01, Terry Steichen wrote:
> Andrew,
>
> I hesitated on making the previous 'rant' because I didn't want to
> come
> off as ungrateful for all the work you, Janne and others have done and
> continue to do. What I did want to do is expose you perhaps a
> different
> perspective than you may normally get. We all are susceptible to the
> COIK fallacy (mentioned below). When I'm working intensely on my
> project, it all seems pretty clear, obvious and intuitive -
> although it
> may be completely opaque to others. I think we all benefit from
> hearing
> things from a different angle (which doesn't mean, of course, that we
> have to agree with it).
>
> Javadocs and source code comments are certainly better than
> nothing, and
> I would agree that in the case of JSPWiki, they are better than many.
> However, what I find frustrating is trying to figure out the overall
> strategy of what's going on - the big picture, if you will. If I use
> JSPWiki in its entirety, with the available look and feel options, the
> standard capabilities of editing pages and providing attachments,
> things
> go pretty smoothly. It's when I need to do things differently (or
> implement stuff that isn't available when I need it) that things
> become
> a bit tougher. The better I can understand the design philosophy, the
> easier that job is.
>
> Regarding my specific comments, what is your reaction to my concern
> about letting login names be changed? For many applications, there
> needs to be some consistent thread of identity (for logging, charging,
> analysis, etc) - how is that to be provided if the login name isn't a
> constant? (The more I think about it, the more I actually think this
> may be a serious problem.)
>
> And I hope I provided enough information on the group changing problem
> for others to verify that it is indeed as I mentioned. (It works that
> way with both my customized version of JSPWiki and the stock
> 2.6.2.) If
> someone else verifies that they see the same thing, then I will add a
> JIRA ticket.
>
> Best,
>
> Terry
>
> On Wed, 2008-05-07 at 11:01 -0400, Andrew Jaquith wrote:
>
>> Terry -- at the risk of making you rant more, I'd simply say the
>> Javadocs are exceptionally detailed, and the source code is well-
>> commented. When in doubt, go to the source.
>>
>> Frankly, I think your expectations a little unrealistic. As somebody
>> who's used a LOT of open source projects, I'd say that our docs (at
>> least the Javadocs, which is really the most important thing for
>> integration) are probably in the top 25% of Java projects I've seen.
>> It beats the crap out of, for example, Jetty and Prefuse (to name two
>> projects I have integrated with lately), but it is not as good as,
>> say, Tomcat or Stripes.
>>
>> I really don't know what to tell you. I'm sorry you find the
>> implementations confusing. I think the other thing you might be
>> missing here is that JSPWiki is now too big for one person to
>> completely comprehend. So, we do the best we can, and we look to
>> volunteers to help out also.
>>
>> Andrew
>>
>> On May 7, 2008, at 10:02 AM, Terry Steichen wrote:
>>
>>> Specific comments inline below.
>>>
>>> <rant - of sorts>
>>> A general comment: It's very hard to figure out how to patch
>>> JSPWiki,
>>> because it's so hard to figure out precisely how some of the
>>> functions
>>> are implemented. For example, I am intrigued by the workflow
>>> capabilities, but haven't a clue as to how to implement them. Same
>>> for
>>> e-mail factories, negative permissions, e-mail authentication,
>>> captcha
>>> capabilities, to name a few. Whenever I've plunged into the JSPWiki
>>> code I've usually come away with being genuinely impressed at the
>>> elegance of the implementation. But that same elegance also
>>> makes is
>>> pretty hard to reverse engineer. (An example of the COIK fallacy -
>>> "Clear Only If Known".) For me, JSPWiki has become a quite
>>> impressive
>>> set of code (helping me to improve my coding skills, among other
>>> things), providing an impressive set of capabilities, but at the
>>> same
>>> time becoming an application that's increasingly difficult to
>>> integrate
>>> custom code with (at least in a way that survives the next version
>>> change).
>>> </rant>
>>>
>>> On Tue, 2008-05-06 at 23:26 -0400, Andrew Jaquith wrote:
>>>
>>>> I do know that
>>>> functionally the works as it should: you can change the various
>>>> names
>>>> in your profile, and ACLs and groups still work. It's worth
>>>> remembering, by the way, that for a long time you could NOT change
>>>> your login name, or wiki name, or full name. Now you can.
>>>
>>> I think we may have become too flexible. Most systems of which I'm
>>> familiar allow you to change just about any element of a personal
>>> profile EXCEPT the login name. Not sure why it's desirable for
>>> JSPWiki
>>> to allow such a change (other than we can do it). Indeed, if we're
>>> logging application-level events, we usually employ the login name
>>> as a
>>> key - but when you allow a person to change that at will, you
>>> lose the
>>> continuity.
>>>
>>>>
>>>> If you need an ironclad guarantee that only particular things are
>>>> changed (e.g., if the login name hasn't changed, don't change the
>>>> login name), the code in GroupManager.actionPerformed() is what
>>>> does
>>>> it. We'd gratefully accept a patch if you want it to work
>>>> differently
>>>> (hint hint).
>>>
>>> A patch would probably be simple, but it seems pointless to
>>> provide a
>>> patch if we're going to allow the login name to be changed at will.
>>>
>>>>
>>>> This isn't a condition we test for as part of web unit tests, so I
>>>> can't tell if this is anomalous to you or not. If it's easy to
>>>> reproduce, then that would help members (and me) figure out if this
>>>> is
>>>> a bug or just local to your customizations. It would also be useful
>>>> if
>>>> we wanted to make a unit test out of it.
>>>
>>> I have no idea on how to make a standardized test for this
>>> condition.
>>> However, the problem is easily shown. When I login and go to
>>> My_Prefs
>>> and change my Name, if I return to My_prefs, I find that I no longer
>>> have membership in any groups (that I previously belonged to).
>>> However,
>>> after I logout and login again, My_Prefs now shows that the
>>> memberships
>>> are restored (using the new Name).
Re: Other 2.6.2 changes
Posted by Terry Steichen <te...@net-frame.com>.
Andrew,
I hesitated on making the previous 'rant' because I didn't want to come
off as ungrateful for all the work you, Janne and others have done and
continue to do. What I did want to do is expose you perhaps a different
perspective than you may normally get. We all are susceptible to the
COIK fallacy (mentioned below). When I'm working intensely on my
project, it all seems pretty clear, obvious and intuitive - although it
may be completely opaque to others. I think we all benefit from hearing
things from a different angle (which doesn't mean, of course, that we
have to agree with it).
Javadocs and source code comments are certainly better than nothing, and
I would agree that in the case of JSPWiki, they are better than many.
However, what I find frustrating is trying to figure out the overall
strategy of what's going on - the big picture, if you will. If I use
JSPWiki in its entirety, with the available look and feel options, the
standard capabilities of editing pages and providing attachments, things
go pretty smoothly. It's when I need to do things differently (or
implement stuff that isn't available when I need it) that things become
a bit tougher. The better I can understand the design philosophy, the
easier that job is.
Regarding my specific comments, what is your reaction to my concern
about letting login names be changed? For many applications, there
needs to be some consistent thread of identity (for logging, charging,
analysis, etc) - how is that to be provided if the login name isn't a
constant? (The more I think about it, the more I actually think this
may be a serious problem.)
And I hope I provided enough information on the group changing problem
for others to verify that it is indeed as I mentioned. (It works that
way with both my customized version of JSPWiki and the stock 2.6.2.) If
someone else verifies that they see the same thing, then I will add a
JIRA ticket.
Best,
Terry
On Wed, 2008-05-07 at 11:01 -0400, Andrew Jaquith wrote:
> Terry -- at the risk of making you rant more, I'd simply say the
> Javadocs are exceptionally detailed, and the source code is well-
> commented. When in doubt, go to the source.
>
> Frankly, I think your expectations a little unrealistic. As somebody
> who's used a LOT of open source projects, I'd say that our docs (at
> least the Javadocs, which is really the most important thing for
> integration) are probably in the top 25% of Java projects I've seen.
> It beats the crap out of, for example, Jetty and Prefuse (to name two
> projects I have integrated with lately), but it is not as good as,
> say, Tomcat or Stripes.
>
> I really don't know what to tell you. I'm sorry you find the
> implementations confusing. I think the other thing you might be
> missing here is that JSPWiki is now too big for one person to
> completely comprehend. So, we do the best we can, and we look to
> volunteers to help out also.
>
> Andrew
>
> On May 7, 2008, at 10:02 AM, Terry Steichen wrote:
>
> > Specific comments inline below.
> >
> > <rant - of sorts>
> > A general comment: It's very hard to figure out how to patch JSPWiki,
> > because it's so hard to figure out precisely how some of the functions
> > are implemented. For example, I am intrigued by the workflow
> > capabilities, but haven't a clue as to how to implement them. Same
> > for
> > e-mail factories, negative permissions, e-mail authentication, captcha
> > capabilities, to name a few. Whenever I've plunged into the JSPWiki
> > code I've usually come away with being genuinely impressed at the
> > elegance of the implementation. But that same elegance also makes is
> > pretty hard to reverse engineer. (An example of the COIK fallacy -
> > "Clear Only If Known".) For me, JSPWiki has become a quite impressive
> > set of code (helping me to improve my coding skills, among other
> > things), providing an impressive set of capabilities, but at the same
> > time becoming an application that's increasingly difficult to
> > integrate
> > custom code with (at least in a way that survives the next version
> > change).
> > </rant>
> >
> > On Tue, 2008-05-06 at 23:26 -0400, Andrew Jaquith wrote:
> >
> >> I do know that
> >> functionally the works as it should: you can change the various names
> >> in your profile, and ACLs and groups still work. It's worth
> >> remembering, by the way, that for a long time you could NOT change
> >> your login name, or wiki name, or full name. Now you can.
> >
> > I think we may have become too flexible. Most systems of which I'm
> > familiar allow you to change just about any element of a personal
> > profile EXCEPT the login name. Not sure why it's desirable for
> > JSPWiki
> > to allow such a change (other than we can do it). Indeed, if we're
> > logging application-level events, we usually employ the login name
> > as a
> > key - but when you allow a person to change that at will, you lose the
> > continuity.
> >
> >>
> >> If you need an ironclad guarantee that only particular things are
> >> changed (e.g., if the login name hasn't changed, don't change the
> >> login name), the code in GroupManager.actionPerformed() is what does
> >> it. We'd gratefully accept a patch if you want it to work differently
> >> (hint hint).
> >
> > A patch would probably be simple, but it seems pointless to provide a
> > patch if we're going to allow the login name to be changed at will.
> >
> >>
> >> This isn't a condition we test for as part of web unit tests, so I
> >> can't tell if this is anomalous to you or not. If it's easy to
> >> reproduce, then that would help members (and me) figure out if this
> >> is
> >> a bug or just local to your customizations. It would also be useful
> >> if
> >> we wanted to make a unit test out of it.
> >
> > I have no idea on how to make a standardized test for this condition.
> > However, the problem is easily shown. When I login and go to My_Prefs
> > and change my Name, if I return to My_prefs, I find that I no longer
> > have membership in any groups (that I previously belonged to).
> > However,
> > after I logout and login again, My_Prefs now shows that the
> > memberships
> > are restored (using the new Name).
Re: Other 2.6.2 changes
Posted by Andrew Jaquith <an...@mac.com>.
Terry -- at the risk of making you rant more, I'd simply say the
Javadocs are exceptionally detailed, and the source code is well-
commented. When in doubt, go to the source.
Frankly, I think your expectations a little unrealistic. As somebody
who's used a LOT of open source projects, I'd say that our docs (at
least the Javadocs, which is really the most important thing for
integration) are probably in the top 25% of Java projects I've seen.
It beats the crap out of, for example, Jetty and Prefuse (to name two
projects I have integrated with lately), but it is not as good as,
say, Tomcat or Stripes.
I really don't know what to tell you. I'm sorry you find the
implementations confusing. I think the other thing you might be
missing here is that JSPWiki is now too big for one person to
completely comprehend. So, we do the best we can, and we look to
volunteers to help out also.
Andrew
On May 7, 2008, at 10:02 AM, Terry Steichen wrote:
> Specific comments inline below.
>
> <rant - of sorts>
> A general comment: It's very hard to figure out how to patch JSPWiki,
> because it's so hard to figure out precisely how some of the functions
> are implemented. For example, I am intrigued by the workflow
> capabilities, but haven't a clue as to how to implement them. Same
> for
> e-mail factories, negative permissions, e-mail authentication, captcha
> capabilities, to name a few. Whenever I've plunged into the JSPWiki
> code I've usually come away with being genuinely impressed at the
> elegance of the implementation. But that same elegance also makes is
> pretty hard to reverse engineer. (An example of the COIK fallacy -
> "Clear Only If Known".) For me, JSPWiki has become a quite impressive
> set of code (helping me to improve my coding skills, among other
> things), providing an impressive set of capabilities, but at the same
> time becoming an application that's increasingly difficult to
> integrate
> custom code with (at least in a way that survives the next version
> change).
> </rant>
>
> On Tue, 2008-05-06 at 23:26 -0400, Andrew Jaquith wrote:
>
>> I do know that
>> functionally the works as it should: you can change the various names
>> in your profile, and ACLs and groups still work. It's worth
>> remembering, by the way, that for a long time you could NOT change
>> your login name, or wiki name, or full name. Now you can.
>
> I think we may have become too flexible. Most systems of which I'm
> familiar allow you to change just about any element of a personal
> profile EXCEPT the login name. Not sure why it's desirable for
> JSPWiki
> to allow such a change (other than we can do it). Indeed, if we're
> logging application-level events, we usually employ the login name
> as a
> key - but when you allow a person to change that at will, you lose the
> continuity.
>
>>
>> If you need an ironclad guarantee that only particular things are
>> changed (e.g., if the login name hasn't changed, don't change the
>> login name), the code in GroupManager.actionPerformed() is what does
>> it. We'd gratefully accept a patch if you want it to work differently
>> (hint hint).
>
> A patch would probably be simple, but it seems pointless to provide a
> patch if we're going to allow the login name to be changed at will.
>
>>
>> This isn't a condition we test for as part of web unit tests, so I
>> can't tell if this is anomalous to you or not. If it's easy to
>> reproduce, then that would help members (and me) figure out if this
>> is
>> a bug or just local to your customizations. It would also be useful
>> if
>> we wanted to make a unit test out of it.
>
> I have no idea on how to make a standardized test for this condition.
> However, the problem is easily shown. When I login and go to My_Prefs
> and change my Name, if I return to My_prefs, I find that I no longer
> have membership in any groups (that I previously belonged to).
> However,
> after I logout and login again, My_Prefs now shows that the
> memberships
> are restored (using the new Name).
Re: Other 2.6.2 changes
Posted by Terry Steichen <te...@net-frame.com>.
Specific comments inline below.
<rant - of sorts>
A general comment: It's very hard to figure out how to patch JSPWiki,
because it's so hard to figure out precisely how some of the functions
are implemented. For example, I am intrigued by the workflow
capabilities, but haven't a clue as to how to implement them. Same for
e-mail factories, negative permissions, e-mail authentication, captcha
capabilities, to name a few. Whenever I've plunged into the JSPWiki
code I've usually come away with being genuinely impressed at the
elegance of the implementation. But that same elegance also makes is
pretty hard to reverse engineer. (An example of the COIK fallacy -
"Clear Only If Known".) For me, JSPWiki has become a quite impressive
set of code (helping me to improve my coding skills, among other
things), providing an impressive set of capabilities, but at the same
time becoming an application that's increasingly difficult to integrate
custom code with (at least in a way that survives the next version
change).
</rant>
On Tue, 2008-05-06 at 23:26 -0400, Andrew Jaquith wrote:
> I do know that
> functionally the works as it should: you can change the various names
> in your profile, and ACLs and groups still work. It's worth
> remembering, by the way, that for a long time you could NOT change
> your login name, or wiki name, or full name. Now you can.
I think we may have become too flexible. Most systems of which I'm
familiar allow you to change just about any element of a personal
profile EXCEPT the login name. Not sure why it's desirable for JSPWiki
to allow such a change (other than we can do it). Indeed, if we're
logging application-level events, we usually employ the login name as a
key - but when you allow a person to change that at will, you lose the
continuity.
>
> If you need an ironclad guarantee that only particular things are
> changed (e.g., if the login name hasn't changed, don't change the
> login name), the code in GroupManager.actionPerformed() is what does
> it. We'd gratefully accept a patch if you want it to work differently
> (hint hint).
A patch would probably be simple, but it seems pointless to provide a
patch if we're going to allow the login name to be changed at will.
>
> This isn't a condition we test for as part of web unit tests, so I
> can't tell if this is anomalous to you or not. If it's easy to
> reproduce, then that would help members (and me) figure out if this is
> a bug or just local to your customizations. It would also be useful if
> we wanted to make a unit test out of it.
I have no idea on how to make a standardized test for this condition.
However, the problem is easily shown. When I login and go to My_Prefs
and change my Name, if I return to My_prefs, I find that I no longer
have membership in any groups (that I previously belonged to). However,
after I logout and login again, My_Prefs now shows that the memberships
are restored (using the new Name).
Re: Other 2.6.2 changes
Posted by Andrew Jaquith <an...@mac.com>.
>>> I noticed with 2.6.2 that when a user changes their fullname, for
>>> all
>>> the groups in which they are a member, their member identifier is
>>> changed from the logname (which I normally use as the identifier) to
>>> the
>>> new fullname. Is that the intended behavior?
>>
>> Yes. This is not configurable.
>
> Why? What's the point of changing the name of the identically-same
> group memberships? Why not leave them as they were - a change in
> fullname would not logically imply a change in a group membership,
> would
> it?
Functionally, what we want to do is simple: when you change your login
ID from "terry" to "steichen", or change your full name, JSPWiki wants
to make sure that ACLs and group memberships don't break. If you
change your login or full name in the user profile, your ACL and group
memberships should still work.
We do this via a search-and-replace type operation after the profile
is saved. We look for any and all of the old Principals (full/login/
wiki name) from the old profile and replace any we find with the
fullname. That might not be good for your purposes, but I do know that
functionally the works as it should: you can change the various names
in your profile, and ACLs and groups still work. It's worth
remembering, by the way, that for a long time you could NOT change
your login name, or wiki name, or full name. Now you can.
If you need an ironclad guarantee that only particular things are
changed (e.g., if the login name hasn't changed, don't change the
login name), the code in GroupManager.actionPerformed() is what does
it. We'd gratefully accept a patch if you want it to work differently
(hint hint).
>>
>>> Second, when the above change occurs, JSPWiki does not appear to
>>> recognize that user's membership in the appropriate groups until
>>> that
>>> user logs out and then logs back in. Is that intended behavior?
>>
>> That is odd. Sounds like a bug. Could you open a JIRA ticket with
>> precise steps to reproduce?
>
> Sure - but I guess my question is whether anyone else has tested this
> and come up with different behavior (from that I described)? Has
> anyone
> changed their fullname and then verified that the normal group
> relationships remained intact without a logout/login? (Remember
> that I
> do have some customized stuff, so I'm never sure how they will
> interact
> with changes in JSPWiki. No point in entering a trouble ticket if I'm
> the only one experiencing it.)
This isn't a condition we test for as part of web unit tests, so I
can't tell if this is anomalous to you or not. If it's easy to
reproduce, then that would help members (and me) figure out if this is
a bug or just local to your customizations. It would also be useful if
we wanted to make a unit test out of it.
Re: Other 2.6.2 changes
Posted by Terry Steichen <te...@net-frame.com>.
On Tue, 2008-05-06 at 20:38 -0400, Andrew Jaquith wrote:
> Many different issues here. Replies online.
>
> On May 6, 2008, at 6:38 PM, Terry Steichen <te...@net-frame.com> wrote:
>
> > I noticed with 2.6.2 that when a user changes their fullname, for all
> > the groups in which they are a member, their member identifier is
> > changed from the logname (which I normally use as the identifier) to
> > the
> > new fullname. Is that the intended behavior?
>
> Yes. This is not configurable.
Why? What's the point of changing the name of the identically-same
group memberships? Why not leave them as they were - a change in
fullname would not logically imply a change in a group membership, would
it?
>
> > Second, when the above change occurs, JSPWiki does not appear to
> > recognize that user's membership in the appropriate groups until that
> > user logs out and then logs back in. Is that intended behavior?
>
> That is odd. Sounds like a bug. Could you open a JIRA ticket with
> precise steps to reproduce?
Sure - but I guess my question is whether anyone else has tested this
and come up with different behavior (from that I described)? Has anyone
changed their fullname and then verified that the normal group
relationships remained intact without a logout/login? (Remember that I
do have some customized stuff, so I'm never sure how they will interact
with changes in JSPWiki. No point in entering a trouble ticket if I'm
the only one experiencing it.)
>
>
> > Third, when typing '[' followed by some characters into the editor, I
> > get a continuous set of "TypeError: el has no properties" alert
> > boxes.
> > What does this mean? More importantly, how do I turn it off?
> >
>
> This doesn't sound like a groups issue per se. Is this a wiki editing
> issue?
Yes, it certainly is an editing question. That's why I changed the
subject of this message to be more general.
Re: Other 2.6.2 changes
Posted by Andrew Jaquith <an...@mac.com>.
Many different issues here. Replies online.
On May 6, 2008, at 6:38 PM, Terry Steichen <te...@net-frame.com> wrote:
> I noticed with 2.6.2 that when a user changes their fullname, for all
> the groups in which they are a member, their member identifier is
> changed from the logname (which I normally use as the identifier) to
> the
> new fullname. Is that the intended behavior?
Yes. This is not configurable.
> Second, when the above change occurs, JSPWiki does not appear to
> recognize that user's membership in the appropriate groups until that
> user logs out and then logs back in. Is that intended behavior?
That is odd. Sounds like a bug. Could you open a JIRA ticket with
precise steps to reproduce?
> Third, when typing '[' followed by some characters into the editor, I
> get a continuous set of "TypeError: el has no properties" alert
> boxes.
> What does this mean? More importantly, how do I turn it off?
>
This doesn't sound like a groups issue per se. Is this a wiki editing
issue?