Right. The renderers need to be updated to render links consistently. So
far, I have avoided touching the renderers. I will work on those later
if I have time. Meanwhile, feel free to create a patch and I will apply it.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/23/2015 7:01 AM, Pierre Smits wrote:
Yes, I thought so too.
But when I use link in a Sreen.xml, like example below:
<link link-type="ajax-window" target=
"newaction?partyId=${parameters.partyId}" width="1000" height="400" text=
"${uiLabelMap.CommonCreateNew}" style="buttontext create"/>
I get a popup window.
Whereas when I use the same in a menu-item, like:
<menu-item name="newaction" title="${uiLabelMap.SEPASetBankAttributes}">
<link link-type="ajax-window" target="nAttributeLayer" title=
"${uiLabelMap.CommonCreateNew}" width="1000" height="600">
<parameter param-name="partyId" from-field="partyId"/>
</link>
</menu-item>
it doesn't open the screen in a popup wind, in stead it renders the new
screen in the browser window.
Best regards,
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
On Fri, Jan 23, 2015 at 3:31 PM, Adrian Crum <
adrian.c...@sandglass-software.com> wrote:
I did that already - in the schema and in code. There is a common link
type, then the various widgets extend it to add their specific attributes.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/23/2015 1:45 AM, Pierre Smits wrote:
Hi Adrian,
Would it not be a good thing to have all the linking definition to be
refactored to one single definiton?
Currently we have:
- link
- hyperlink
- sub-hyperlink
It seems to me that they are intended to deliver the same functionality,
but are applied differently per application area:
1. link -> menu, screen - but with different behaviour between the
two,
e.g. ajax-window doesn't work in a menu
2. hyperlink -> forms, commonly used to have a link associated to a
field
3. sub-hyperlink -> forms, commonly used in a display entity
associated
to a field
Best regards,
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
On Mon, Jan 19, 2015 at 7:30 AM, Gavin Mabie <kwikst...@gmail.com> wrote:
Yes. Cell/Column sizes in conjunction with screen media directives can
then be used to achieve responsive layouts.
On Mon, Jan 19, 2015 at 7:13 AM, Adrian Crum <
adrian.c...@sandglass-software.com> wrote:
So, you're suggesting a grid widget would accept any screen widget
within
a cell? That could be done fairly easily.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/18/2015 8:49 PM, Gavin Mabie wrote:
With columns already existing, rendering them inside rows would
constitute
a grid.
On Sun, Jan 18, 2015 at 6:19 PM, Adrian Crum <
adrian.c...@sandglass-software.com> wrote:
We have columns for that.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/17/2015 6:14 PM, Gavin Mabie wrote:
Hi Adrian
I like the grid idea. It will almost certainly simplify and enhance
UI
design. Furthermore, it will facilitate responsive design in Ofbiz. I
agree that form widget should apply to forms. I would recommend that
we
create a table widget for multi-column lists instead of the proposed
grid
widget. My thinking is that the grid widget should be used as a
layout
widget on a level just beneath screens but higher than lower level
widgets
(screenlets/forms/tables/menus/trees). In other words a screen
contains
grids and grids contain lower level widgets. This pattern will
enable
us
to make Ofbiz truly responsive. What do you think?
Gavin
On Sat, Jan 17, 2015 at 7:46 PM, Adrian Crum <
adrian.c...@sandglass-software.com> wrote:
Some time ago I started working on the screen widget thread
safety.
There
were many places in code where widget models were being modified
during
rendering - resulting in unpredictable behavior, and in some cases it
resulted in users having access to data they shouldn't be able to
see.
While doing that work, I was overwhelmed by the quantity of source
code.
The screen widget library was built using a lot of copy-and-paste -
instead
of extracting and reusing common things. Scott started working on
reusing
widget code, but that was just a small beginning.
In a recent commit, I continued his work and made some more things
reusable.
Next, I would like to reorganize the source code folder structure.
Here
is
what I have pictured:
org/ofbiz/widget
artifact (Artifact Info classes)
cache (Widget cache classes)
model (Widget models)
renderer (Widget renderers)
macro
html
xml
I think the simplified folder structure makes more sense and it will
make
it easier to locate classes.
After that, I would like to add error checking code to the widget
models
-
similar to what I did in Mini-Language. Right now, errors in widget
XML
are
(sometimes) logged and widget parsing continues. If a developer does
something wrong, they will not know it unless they check the logs. I
would
like to change the behavior so widget XML errors throw an exception
with
a
detailed error message that includes the XML file name and line
number
where the error occurred. I believe this will benefit developers by
making
it clear when they have done something wrong.
Finally, I would like to extract list functionality from the form
widget
and create a new grid widget. So, instead of a form widget
representing a
single data entry form OR a list, it will ONLY represent a single
form.
If
you want a list, you use the grid widget. Initially, this change
will
be
backwards-compatible - the XML parser will accept a <form> element
for
both
types and it will create the correct model based on the type
attribute.
Overall, my goal is to make screen widgets more developer-friendly,
and
also to make it easier to innovate in the screen widget component.
After all of this work is completed, I would like to backport it to
the
R14 branch.
Comments are welcome.
--
Adrian Crum
Sandglass Software
www.sandglass-software.com
