Re: silva-2.2: comments
Marc Petitmermet <[email protected]> Tue, 2 Jun 2009 12:51:31 +0200
| Newsgroups | gmane.comp.web.zope.silva.devel |
|---|---|
| Message-ID | <[email protected]> |
On 02. Jun 2009, at 02. Jun 2009|05:15 Uhr, Andy Altepeter wrote:
> Hi Marc,
>
> Thanks for your feedback. I'll address the items I can below:
>
> On Sunday 31 May 2009 03:55:31 pm Marc Petitmermet wrote:
>> uploading image:
>> why do i have to browse again for the image when i forgot to enter
>> the
>> required title?
> I think this is standard web behavior for file input fields. The
> path isn't
> sent to the server (that's a security issue), only the contents of
> the file.
> So unfortunately it is impossible for Silva to re-populate the image
> path.
i have a silva code source for uploading files (original by benno) and
there i don't have to re-enter the file again when i forget a required
field and it is also of input type="file". so it is possible to keep
the content of this field. the filename is read using:
filename = getattr(file, 'filename', None)
>>
>> edit link reference...:
>> i was a little surprised about what happened when clicking on this
>> new
>> icon in the kupu link tool. sometimes we have long urls/paths and it
>> is not that easy to fix those because of the need of horizontal
>> scrolling. so i expected that this button opens up a larger link
>> field
>> that would help me in this situation. but instead it opened up the
>> silva document where it linked to. therefore, could you please rename
>> the tool tip from "edit link reference..." to "edit linked
>> reference...". small detail but the two character change makes the
>> description correct.
> This is a good catch; thank you. I understand what you mean about
> editing
> long links. Do you think that if the link is long, the input field is
> switched to a textarea when it has the focus? If the textarea
> wrapped rather
> than added a scrollbar, it may be easier to edit long links...
well, let's give it a try. this is at least better than my current
workaround: copy the url to a text editor, fix the errors and copy it
back to kupu...
>
>> edit link(ed) reference...:
>> is it possible to have the button "edit link(ed) reference..."
>> disabled from the beginning for not valid relative silva references?
>> currently, it gets disabled after the user has clicked on it, that's
>> too late and useless because the next time the cursor is on the same
>> link the button is enabled again.
> By disabled, do you mean that it would be sufficient to do nothing
> if the
> reference wasn't "editable"?
yes. i would only change the tool tip text.
>
>> warning message: what is the definition of "valid relative silva
>> references"? what about "valid absolute silva references", won't they
>> be edited? don't you mean local and external references here?
> An ajax call to Silva happens whenever the button is clicked and
> there is text
> in the input field. Silva then determines if the text is a link to
> a Silva
> object, and returns an absolute edit url. If it isn't an editable
> link, the
> alert message is displayed.
>
> This initial implementation needs relative links, which are the
> easiest to
> resolve to Silva objects. If it has to deal with absolute urls,
> Silva then
> needs to know how to translate a server name to the root of a vhost
> within
> Silva. A single silva root could support multiple virtual hosts,
> but Silva
> doesn't necessarily know that. It only knows about the vhost you're
> accessing from.
>
> I recall Kit and I chatting about this feature. I had forgotten
> this, but we
> decided to try out absolute urls for the host you're accessing silva
> from as
> well. Zope does provide a nice method to translate this type of
> absolute url
> into a zope path. I'll put this on my list.
>>
>> lookup users.../groups admin...:
>> i think since silva-2.1 (i don't know about 2.0) the "lookup
>> users..."/"groups admin..." buttons have been moved away from their
>> boxes on the right side to the top left side of the smi. i miss them
>> at their old locations, it was much more convenient.
> I didn't make this change, so I can't really comment other than to
> say I agree
> with Marc. My muscle memory is stronger than the standardization of
> actions
> into the middleground.
>>
>> export to open document (odt):
>> nice that this feature is now built in. i had quite good experience
>> with https://viewvc.infrae.com/svn/silva2odt/ by dave kuhlmann. this
>> built in export has still a few issues like missing images, list
>> styling, export of complete branches.
> Is there a launchpad bug to tracking these issues? I can only hope
> Dave will
> come out with version 2 of silva2odt which includes these features...
>>
>> user settings:
>> is it possible to have the languages somehow sorted?
>
> How would you think these should be sorted? It doesn't appear this
> list is
> sorted in any particular order. Do you think the language code is
> more
> natural than a string-comparison sort on the language names? We only
> use 'en' over here in the states, so I really have no idea...
one idea could be to use the same language codes like in firefox (iso
country codes?). maybe those could be added before the country name
and sort them using always these codes. e.g. EN English, DE German.
this would also work with DE-DE, DE-CH, DE-AU, etc. this would also
help if somebody accidentally chose e.g. chinese and can't find the
way back to english.
regards,
marc