[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
hi ekke,
Am 11.08.2008 um 00:39 schrieb ekkehard:
hi christian,
thanks for the answer...
Christian Campo schrieb:
Hi Ekkehard,
the short answer is:
- yes we only implement a toolbar on the top, the view is something
drawn by the View class. normally we dont have a toolbar there and
we think its confusing if it has one.
normaly I would do it the same way
If you have a different opinion on this (why not), not might also
build your own view and add a toolbar inside there.
but there are some special cases (for special business users) where
I'll need a toolbar inside the view
good to hear that its possible
I admit we havn't tried it, but I guess its a matter of trying out and
if it doesnt work, you should file a bug report
- I am not sure why you would like to drag from the navigation to
the Workarea (view on the right). maybe you can explain what you
wonna do. if you are talking about shift the navigation to the
right side, that is currently not a planned feature. but I dont
think that is what you were asking for.
yes, thats not what I'm asking for
imagine at the right a view with some business data
and at the left a list or tree and dragging one of the entries left
to a field right will cause an action / insert data etc.
correct the left side exists for the navigation and is not a data view.
...but from your answer it seems that at the left there's only place
for navigation trees ?
imagine following situation:
a disponent of trucks sees at the left available trucks he is
responsible for
and at the right in the top half he has open orders
then he dragged a car on a specific order and then in a table in the
bottom half of right view an entry appears with this truck and order
and the truck disappears from left ond the ordr disappears from top
half right view
its not the exactly way - should only show the things that should be
possible
if the left part is only navigation, then I have to move the list of
trucks into the right view
right
- we are also not planning on having a fullsize view again because
the navigation should always be visible. you can resize the whole
application and by this make you view area larger
I've seen that I can resize the window, but it would be great (for
my users) to toggle the navigator on/off
ok but seems to colide with the intentions of Riena I guess. The
navigation at the left is meant to be the central and nearly only way
to navigate between views (with the exception of menu and coolbar). if
you make the navigation temporarily invisible, how do you change to a
different view ? the user need to resize the application first and
then click on the navigation. While that might be something you want,
it sounds more like you dont need or dont want the navigation at all.
How would you then switch between the different views of your
applications ? Are you planning on only doing that my coolbar items
for example because there are only like 5 or 10 views ? So that can be
an option. So that means you want a Riena application without the
navigation to appear ?
Is that what you want ?
- we are right now make the use of Riena more understandable and
easy to use.
:-)
I can explain that in a little bit detail in a mail tomorrow.
great !
One goal is to use Tools like SWT Designer to layout Riena views.
(I did a little research on that in the last week).
exactly what I need
- the other part is allowing people to use Riena features like
ridgets and all their APIs without "buying" into the whole Riena
concept.
I was thinking about this, but because of lack of knowledge of the
Riena concepts I wasn't sure if this would be possible
of course it would be nice if I can live with the things I'm buying
with the Riena concept
So you should be able to just have one widget wrapped by a ridget
in a regular RCP application and then maybe create a whole view and
use ridgets for them but still within RCP.
sounds great - then I can use the cool Riena features if my decision
would be not to use the whole Riena UI because of some restrictions
Riena's Ridgets are a wrapper around regular widgets. Most if not all
samples that we have, use different classes for View and Controller.
The View uses Widgets and layout and these SWT thingys
to layout the whole view. In there you do stuff like addUIControl to
add the widget to a container under a specific name. So later you
could distinguish a TextField that contains the Firstname from the
TextField that contains the lastname. In the process of Binding the
View with the Controller instance, we create Ridgets for each and
every Widget that was added to the View with addUIControl. The Ridgets
contain no dependency to SWT anymore, Ridgets are Interfaces. The are
a higherlevel concept than widgets because they not only allow you to
set the text value in the widget but also do stuff like
- databinding = binding the ridget again a property in your model
- validation = adding validation rules to your ridget that are either
checked for each char or when focus is lost in the widget
- marker support = marking fields where validation rules fail, marking
fields as read only or as mandatory, later field error markers will
also create an error marker in the navigation tree
- ridgets are and will be able to have a higher specialication grade
than widgets can (i.e. there is only a Tree and a Table widget, we
also have a Tree, Table and a TreeTable (which can be grouped, a
regular textfield can be a DateTextRidget, NumberTextRidget etc. that
will not only include validation but also formatting and so on)
So one advantage (as pointed out by Elias previously) is that you have
class that contains all the methods for dealing with these different
aspects rather than learning about JFace Databinding, IValidators,
TreeViewers etc, which are used by Riena internally. Ridgets of course
also offer Listener APIs and if all that fails for you, you can still
access the original widget that is wrapped by the Ridget.
Currently that means that the view and the controller are different
classes bound by the Binder. We, Elias is working on lower that
burden, so that you should be able to create a Ridget for any Widget
that you like.
We currently have Ridgets for most Widgets, but i guess not for all of
them. Also we currently dont yet have an easy way for you as an
application programm to have customer ridgets or custom mappings from
widget to ridget. That is certainly necessary but will take some time.
Does that help in any way ???
regards
christian
this is coming, however not finished.
more on that tomorrow.
I'll wait ... ;-)
if you have more questions, please let me know
they will come
last weeks I had much work with EasyBeans to make it run with 500+
SessionBeans, 1000+ Business Interfaces, some PersistenceUnits /
DataSources.
this seems to work now at server site, all starts up automatically
and then starts my Riena stuff
of course I'm waiting for some bugfixes from EasyBeans and for an
important enhancement:
EasyBeans already registers all my EJB Interfaces as OSGI services,
but without the possibility to give them some properties I need to
use them as Riena remote services. But they understand and will make
the Services manageable so I can add the properties :-)
next week will be intensive GUI testing for Riena and make
decisions, then 2 weeks holiday, then (hopefully with M4) work on UI
again
thx for help
ekke
_______________________________________________
riena-dev mailing list
riena-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/riena-dev
