Hi Tomasz I think it looks really nice. I'd just prefer to rename "Fiter" to "Settings" and "Edit details" to "Filter" - because "Filter" settings are just some of the settings which users will want to change. But I'm OK with Filter/EditSettings as well for now...
Please go ahead with implementing the search feature :-) thanks, Sergey On Sun, Sep 19, 2010 at 10:06 PM, Tomasz Oponowicz < tomasz.oponow...@gmail.com> wrote: > Hi Sergey, > > On Tue, Sep 14, 2010 at 11:33 PM, Sergey Beryozkin <sberyoz...@gmail.com> > wrote: > > Hi Tomasz > > > > sorry for a delay > > > > On Fri, Sep 10, 2010 at 4:01 PM, Tomasz Oponowicz > > <tomasz.oponow...@gmail.com> wrote: > >> > >> Hi Sergey, > >> > >> Welcome everyone after quite long break. > >> > >> I've prepared sample user interface for "search capabilities" feature. > >> > > > > Great :-) > > > >> > >> Legend: > >> > >> * File [0]: > >> > >> 1) "All endpoints" entry is added after moving to "search" mode > >> (this entry isn't shown during "browsing mode"). > >> If user choose particular endpoint, the application will > >> search log entries only within chosen endpoint; > >> > >> 2) User is informed that he is currently at "search mode". > >> He can return to "browsing mode" by clicking "reset" link; > >> > >> 3) "Advanced" checkbox shows or hides additional inputs like: from > >> date, to date and levels; > >> > >> 4) This button has two functions. First of all it shows what > >> levels are enabled. > >> For example when only INFO and ERROR levels are enabled then > >> label of the button has value "I/E". > >> Second of all popup is showed after clicking button (more info > >> in next section); > >> > >> * File [1] > >> > >> 1) Popup contains all possible log levels. Click on specified > >> level to enable or disable level. > >> If user click outside the popup, popup will disappear and new > >> configuration will be saved. > >> > >> Of course it's only a concept - all improvements are welcome. > >> > > > > I'm not quite sure I'd like, as a user, to switch between 'browsing' and > > 'searching' modes. > > I'd like to work in a single mode, the way I can do it right now by > adding > > endpoints, clicking between them and looking at corresponding log > entries. > > > > As I suggested earlier on, it would be nice for a start to have global > > search properties which apply to all the endpoints, just making it easy > to > > configure in a very non intrusive way would be something which will let > us > > move the code to the trunk. > > > > Thinking ahead, perhaps we can have what is the log browser now turning > into > > a management UI where another tab would probably show the statistics > > (exchanges, etc) collected with the help of persisting interceptors. Thus > > I'm not sure if we can have a *menu* right now. > > > > Perhaps a pop-up window allowing to set search properties would do. > > Have a look please at Google Mail 'More Actions' which shows a number of > > menu items, one of them is "Create Event" which allows to set the event > > properties. So if we could have a button in the top right cotton > "Settings" > > which, once pressed, would show only "Filter..." or "Search..." which in > > turn would lead to a pop-up window where a user would select how to > search > > and press OK. From then on every endpoint will use this filter/search > > conditions. > > > > I've prepared new interface by taking all good ideas into consideration. > > At the [0] screenshot there is "explore" mode. I modified left sidebar > by adding stack panel. In the future we can add more children (for > example "statistics" header etc.). I think this solution is very > flexible. At the [1] screenshot there is "filter" mode. It looks > almost the same but there is additional "Edit criteria" link. User can > easily swap between this two modes. After pressing "Edit criteria" > link, dialog box is shown for modifying criteria [2]. > > I think this solution is good enough, so if you approve it I will begin > coding. > > What do you think? > > > Additionally, if really needed, users could override the settings on a > > per-endpoint basis. Possibly by right-clicking on a specific endpoint and > > selecting "Filter..." or "Search..." from a popup menu. > > > > Do you think it's doable ? > > Yes, no problem at all. I think it's good feature for future. > > >> > >> I have got some technical question. How do you consider paging for > >> "All endpoints"? Because every endpoint is independent the only > >> solution would be gathered page from all endpoints and combine into > >> one huge page. Unfortunately I don't like this solution. Have you got > >> any idea? > >> > > Perhaps we should not introduce such a composite endpoint at this stage ? > > This would just make things much more complicated. AtomPullServer allows > one > > to search from the external file but I'm not sure yet how to deal with > that > > in the browser. You are right in that all the logs should be shown, but > lets > > discuss it once we have the code on the trunk :-) > > I introduce "composite endpoint" because of my misunderstanding. I > also agree that it would be problematic. > > > [0] > https://issues.apache.org/jira/secure/attachment/12454988/searching_layout_explore_v2.png > [1] > https://issues.apache.org/jira/secure/attachment/12454987/searching_layout_filter_v2.png > [2] > https://issues.apache.org/jira/secure/attachment/12454989/searching_layout_edit_criteria_v2.png > > -- > Best regards, > Tomasz Oponowicz > > > thanks, Sergey > > > >> [0] > >> > https://issues.apache.org/jira/secure/attachment/12454295/searching_layout_v1.png > >> [1] > >> > https://issues.apache.org/jira/secure/attachment/12454296/searching_layout_with_popup_v1.png > >> > >> -- > >> Best regards, > >> Tomasz Oponowicz > >> > >> On Mon, Aug 30, 2010 at 1:11 PM, Tomasz Oponowicz > >> <tomasz.oponow...@gmail.com> wrote: > >> > Hi, > >> > > >> > GSOC has just ended. During this time LogBrowser was created. At the > >> > moment the project has all basic features like authentication, > >> > settings manager and browse layout which includes navigation links > >> > (first, previous, refresh, next and last page). I would really like to > >> > continue working with Apache CXF community. Together with Sergey, we > >> > think about how to extend the project to make it even more useful. > >> > > >> > We consider two crucial features right now: > >> > > >> > 1. search capabilities; > >> > 2. removing authentication when connection is not secure (it is not > >> > HTTPS); > >> > > >> > Below our discussion about that (we have some spam filter difficulties > >> > and this is why it looks so weird). > >> > > >> > =According to search capabilities= > >> > > >> > [Sergey] > >> > > >> > Offer some basic search options first, I think they should be global > >> > for a start, i.e, they'd apply to all the endpoints. Ex : a user is > >> > offered a list of level options (level: INFO or DEBUG), just this > >> > would do, so the user would select : I'd like to see INFOS only, and > >> > then a FIQL expression is sent to AtomPullServer and it would just > >> > return the list of matching records. > >> > > >> > [Tomasz] > >> > > >> > I agree that search option is crucial feature right now. I think there > >> > should be available search criteria as follows: > >> > > >> > 1) specified phrase; > >> > 2) datetime range: begin and end datetime; > >> > 3) log entry level: INFO, etc; > >> > > >> > ...all parameters will be sent to AtomPullServer as FIQL expression > >> > (as you mentioned). > >> > > >> > Although I think it's better to have search only within current > >> > selected endpoint. We give an user an ability to divide all logs into > >> > plenty of endpoints for clean browsing but now we will search through > >> > all endpoint at once. I think it breaks basic assumption. However > >> > searching within selected endpoint isn't a problem, because > >> > AtomPullServer has powerful configuration capabilities and user can > >> > easily combine many loggers into one instance through "setLoggers" > >> > method. > >> > > >> > What do you think about that? I think searching within current > >> > selected endpoint is good enough. > >> > > >> > [Sergey] > >> > > >> > Sounds ok, not sure about phrases but I guess it can be useful, I > >> > thought users would really would like to see all the error messages or > >> > indeed all the messages logged during some specific limited period of > >> > time, but phrases may probably help those who know what sort of log > >> > messages can be expected to narrow down the set to virtually a single > >> > message or just few of them... > >> > > >> > [Sergey] > >> > > >> > May be you're right that it's better to have individual endpoint > >> > having specific search conditions. But I'd really like to enter the > >> > common search conditions, say, say show me the message with INFO level > >> > only only, and then start clicking between multiple endpoints and see > >> > the INFO logs only. However, I'd likely want to customize the way the > >> > search conditions get applied to a given endpoint > >> > > >> > So how about being able to specify the search condition that applies > >> > to all the endpoints first and once it all works ok, add the > >> > capability to override it on per-endpoint basis ? Or the other way > >> > around. I'd not be concerned about making both options work before the > >> > merge to the trunk, just > >> > > >> > -- > >> > Best regards, > >> > Tomasz Oponowicz > >> > > > > > >
