Problems I’ve seen:
- Title of the page is always “Tori”.
- The dropdown next to the Dashboard breadcrumbs has two entries, 9 - Addons and 9 - Vaadin 7.
- Emoticons are missing.
- Does not remember scroll position when you click the browser’s back button.
5. Latest Post column seems to have the timestamp for when the thread was created, not the timestamp for when the last post was added.
My bad, I missed the tiny pushpins on the left side indicating that they were sticky threads…
- When on the “Recent Posts” list, clicking the “Recent Posts” link again does not refresh the page.
Good feedback. I’ll make sure it gets passed along the the relevant people.
Hi,
Thanks for your feedback! I’ll try to answer each here.
This problem originates from when there was no proper API for portlets to change the title of a page, and early Vaadin 7 API didn’t provide a workaround for that either. I checked, and it should work now with the introduction of the Page class/object. The original ticket is
#120
This is actually due to the configuration of vaadin.com, and isn’t specific to Tori itself. You can see the same categories
in the old forums
.
That’s curious, and something I didn’t notice before. Tori uses the same post-formatting logic that Liferay provides, but apparently Liferay does some custom work to enable emoticons. I added a new ticket:
#280
- thanks!
This is actually a problem that’s unfortunately hard to solve in the Vaadin space. There are already a few tickets open regarding this:
#91
,
#271
Quite correct, this is another thing I haven’t noticed myself before. The technical reason for this is that RIA applications like Tori handle navigation with the URI fragment (the part that comes after the #-sign in the address). While I don’t have the specification at hand, it appears to be standard that applying the same fragment twice doesn’t fire any events in the browser, therefore there’s no navigation going on. This should be worked around on Tori’s part! I added a ticket
#281
Vaadin 7 default is that navigating to the same fragment causes it to destroy and recreate the UI while navigating to another fragment is only a fragmentChange. This behavior can be changed with the UI annotation @PreserveOnRefresh. Don’t know however how Liferay affects this.
Tori doesn’t use Vaadin 7’s Navigator, but uses its own. Also, since Tori tries to use as much -tags as possible, to allow the user to use links in Tori as naturally as possible (“open in new tab” primarily), the browser doesn’t fire the
window.onhashchange
event when “changing” the fragment back to itself. So, the way to fix this is to add an auxiliary event to the same button to work around this way, and handle the “change to itself” thing manually somehow.
I could not find “search” and “subscriptions” in the new forum Will this be available in the future?
Search is very low in the current priority list. This uses Liferay as its back-end, so there would be very little Tori could offer to improve or modify the way Liferay searches through it archives. The site itself already has a search field (top right corner of the screen, in the header), and that will search through the same data that Tori could search. I recommend to use that instead - there’s no real point in having two nearly identical search fields on top of each other.
The list of subscribed-to threads isn’t planned, but might be a good addition. I can’t promise any development deadlines, since Tori has taken a lot of time to develop, and we need to do other stuff for a change too. You still get emails sent to your email address for when you subscribe to threads. In Tori, the verb is now “follow”, and you can follow/unfollowing threads by pressing on the little wrench icon to open the menu for that particular context. As a workaround, I’d suggest using the “My Posts” list, to see the threads you’ve written to.
Usabililty Suggestion: the captions on the buttons for the “Edit Post” function are a little obtuse : Edit Button → Popup containing editable post, and then buttons labeled “Edit” and “Close Editor”.
I would suggest that “Save” and “Cancel” would be clearer!
The site-search doesn’t seem to find anything in the forum. E.g. when I search for “Tori”, the site-search doesn’t find anything, whereas the search of the old forum finds some messages.
I have to disagree here - “save” and “cancel” are more commonly used around user interfaces, sure, but that’s more of a legacy “because the other guys did it too” thing. Generally, having the buttons’ captions be more context-sensivite in terms of wording is better. E.g. “Yes, Shut Down” and “No, Resume Work” is better than “OK” vs “Cancel”.
Anyways, I can agree that “edit” could be reworded as “save edits” or some such. But in this particular context, “close editor” tells exactly what will happen, while “cancel” doesn’t reveal what the button does: If you modify some text in the pop-up, close the editor and then reopen it, you’ll see that your changes aren’t erased - the editor was simply closed.
I’m happy to tell you that the edit functionality as it currently is implemented is a “good enough” solution. We have plans and wireframes for a
way
better way to edit a post. We just needed to concentrate on performance optimization instead of doing the work needed for our vision here.
You caught me a bit red-faced here: The site search indeed uses Google’s search, and not Liferay’s back end at all, as I remembered. In any case, it’s weird that you don’t find anything in the site search, since I find several hits on the word “Tori”. Did you narrow the search down to the “forum” tab?
This is true, yes; but so is the fact that we (well, most of us) use a QWERTY keyboard layout 
Yes
there was a rational reason behind it originally
, but the advantages provided by it withered away over time and we are left with what seems to be a pointless layout - but very difficult to change because of the legacy ! Anyway, a longish way of saying “Hey, I disagree too” but that’s cool.
For what it’s worth, “Save Edits” would be better IMHO - I absolutely agree that more context is important on dialogue buttons. I didn’t realise that the “Close Editor” didn’t cancel.
In the scheme of things, though, the caption on these buttons isn’t really important - just something I noticed and thought I’d mention!
I thought the search would start when I enter something in the search field and press enter, but it only works when I click the search button on the following Search-page (which I thought is already the result page).
Hi
I have found a strange behavior when i come from an external page. If i search on google and click on an entry, the vaadin forum doesn’t show me the thread.
Here is an example: Search on Google for “vaadin table line wrap”. The first entry is this link: https://vaadin.com/de/forum/-/message_boards/view_message/1389905
On click i forward to the Dashboard.
Greets
Hm, that sounds strange. For me, it works pretty well out of the box: If I type “Book of Vaadin” in the search box, and press enter, I’m taken to a results page where Book of Vaadin is the first hit.
This seems to be linked to the fact that there’s a “/de/” in the URL, which tells Liferay to localize the page (and Tori doesn’t support that currently). This issue is already known, and if everything goes well, a fix will be deployed pretty quickly.
Sorry about that, replied with my test user alter-ego by mistake 