Re: svn commit: r422052 - /incubator/ofbiz/trunk/applications/order/webapp/ordermgr/order/orderlist.ftl

[David E Jones-2]

Is there a reason for doing this?

In general with dates in OFBiz if we move away from the standard format that is used everywhere (the descending format that is the default for Timestamps) we open a Pandora's Box of issues with localization and which of the details to include or leave out. It also opens issues with confusing users as to the format to use when entering date/time information if it is not consistent with the output presented by the applications.

These are not issues I want us to be dealing with in the core OFBiz applications...

In general please don't be too quick to change things, especially that are related to established patterns. Many of these were established after years of feedback and trying different things and there are always trade-offs with such things that one must watch out for.

-David


[hidden email] wrote:

> Author: sichen
> Date: Fri Jul 14 14:16:54 2006
> New Revision: 422052
>
> URL: http://svn.apache.org/viewvc?rev=422052&view=rev
> Log:
> Changed the date format in orderlist to be something more user friendly.
>
> Modified:
>     incubator/ofbiz/trunk/applications/order/webapp/ordermgr/order/orderlist.ftl
>
> Modified: incubator/ofbiz/trunk/applications/order/webapp/ordermgr/order/orderlist.ftl
> URL: http://svn.apache.org/viewvc/incubator/ofbiz/trunk/applications/order/webapp/ordermgr/order/orderlist.ftl?rev=422052&r1=422051&r2=422052&view=diff
> ==============================================================================
> --- incubator/ofbiz/trunk/applications/order/webapp/ordermgr/order/orderlist.ftl (original)
> +++ incubator/ofbiz/trunk/applications/order/webapp/ordermgr/order/orderlist.ftl Fri Jul 14 14:16:54 2006
> @@ -139,7 +139,7 @@
>                  <tr><td colspan="8"><hr class="sepbar"/></td></tr>
>                  <tr>
>                    <td>
> -                    <div class="tabletext">${orderHeader.orderDate.toString()}</div>
> +                    <div class="tabletext">${orderHeader.orderDate?string.medium_short}</div>
>                    </td>
>                    <td>
>                      <div class="tabletext"><a href="<@ofbizUrl>orderview?orderId=${orderHeader.orderId}</@ofbizUrl>" class="buttontext">${orderHeader.orderId}</a>
>
>

[Si Chen-2]

Oops.  Sorry about that.  I just saw a bunch of outstanding changes  
on my version.  I'll revert it.

Si


On Jul 14, 2006, at 2:29 PM, David E. Jones wrote:

>
> Is there a reason for doing this?
>
> In general with dates in OFBiz if we move away from the standard  
> format that is used everywhere (the descending format that is the  
> default for Timestamps) we open a Pandora's Box of issues with  
> localization and which of the details to include or leave out. It  
> also opens issues with confusing users as to the format to use when  
> entering date/time information if it is not consistent with the  
> output presented by the applications.
>
> These are not issues I want us to be dealing with in the core OFBiz  
> applications...
>
> In general please don't be too quick to change things, especially  
> that are related to established patterns. Many of these were  
> established after years of feedback and trying different things and  
> there are always trade-offs with such things that one must watch  
> out for.
>
> -David
>
>
> [hidden email] wrote:
>> Author: sichen
>> Date: Fri Jul 14 14:16:54 2006
>> New Revision: 422052
>> URL: http://svn.apache.org/viewvc?rev=422052&view=rev
>> Log:
>> Changed the date format in orderlist to be something more user  
>> friendly.
>> Modified:
>>     incubator/ofbiz/trunk/applications/order/webapp/ordermgr/order/
>> orderlist.ftl
>> Modified: incubator/ofbiz/trunk/applications/order/webapp/ordermgr/
>> order/orderlist.ftl
>> URL: http://svn.apache.org/viewvc/incubator/ofbiz/trunk/ 
>> applications/order/webapp/ordermgr/order/orderlist.ftl?
>> rev=422052&r1=422051&r2=422052&view=diff
>> =====================================================================
>> =========
>> --- incubator/ofbiz/trunk/applications/order/webapp/ordermgr/order/
>> orderlist.ftl (original)
>> +++ incubator/ofbiz/trunk/applications/order/webapp/ordermgr/order/
>> orderlist.ftl Fri Jul 14 14:16:54 2006
>> @@ -139,7 +139,7 @@
>>                  <tr><td colspan="8"><hr class="sepbar"/></td></tr>
>>                  <tr>
>>                    <td>
>> -                    <div class="tabletext">$
>> {orderHeader.orderDate.toString()}</div>
>> +                    <div class="tabletext">$
>> {orderHeader.orderDate?string.medium_short}</div>
>>                    </td>
>>                    <td>
>>                      <div class="tabletext"><a  
>> href="<@ofbizUrl>orderview?orderId=${orderHeader.orderId}</
>> @ofbizUrl>" class="buttontext">${orderHeader.orderId}</a>

[Leon Torres-2]

David E. Jones wrote:
>
> Is there a reason for doing this?

It's an interesting question about what the date format should be for an
application.  Is there an ofbiz date format configuration somewhere to use that
would transform *all* these timestamps to something a client would want?  If
not, will it ever be resolved?

It could be as simple as overloading the Timestamp.toString() method and
replacing it with something ofbiz-ish.  Not sure how easy that is in Java.

- Leon

[Adam Heath-2]

David E. Jones wrote:
> In general please don't be too quick to change things, especially that
> are related to established patterns. Many of these were established
> after years of feedback and trying different things and there are always
> trade-offs with such things that one must watch out for.

Ok, so what are the established patterns?  Are they documented anywhere?
  If no one knows them, then expect to have more of this in the future.

[David E Jones-2]

The best info to date on these things would be the Framework Introduction videos and the Best Practices Guide.

Of course, anyone who has spent enough time with OFBiz to have commit access in a certain area should be familiar enough with the artifacts in that area to recognize the established patterns.

It's just like any effort to maintain consistency: precedence is the key. Of course, precedence should be questioned and reconsidered regularly and sometimes even changed.

If this is a problem, it is the duty of the community (including me and all of us on this mailing list) to fix it, especially those who consider it a problem.

-David


Adam Heath wrote:
> David E. Jones wrote:
>> In general please don't be too quick to change things, especially that
>> are related to established patterns. Many of these were established
>> after years of feedback and trying different things and there are
>> always trade-offs with such things that one must watch out for.
>
> Ok, so what are the established patterns?  Are they documented anywhere?
>  If no one knows them, then expect to have more of this in the future.

[cjhowe]

That's very interesting, David.  Considering that
questioning of patterns is exactly what was being done
in OFBIZ-81 and you of all people prompted others to
dismiss the idea, even when the problem was
articulated.

--- "David E. Jones" <[hidden email]>
wrote:

>
> The best info to date on these things would be the
> Framework Introduction videos and the Best Practices
> Guide.
>
> Of course, anyone who has spent enough time with
> OFBiz to have commit access in a certain area should
> be familiar enough with the artifacts in that area
> to recognize the established patterns.
>
> It's just like any effort to maintain consistency:
> precedence is the key. Of course, precedence should
> be questioned and reconsidered regularly and
> sometimes even changed.
>
> If this is a problem, it is the duty of the
> community (including me and all of us on this
> mailing list) to fix it, especially those who
> consider it a problem.
>
> -David
>
>
> Adam Heath wrote:
> > David E. Jones wrote:
> >> In general please don't be too quick to change
> things, especially that
> >> are related to established patterns. Many of
> these were established
> >> after years of feedback and trying different
> things and there are
> >> always trade-offs with such things that one must
> watch out for.
> >
> > Ok, so what are the established patterns?  Are
> they documented anywhere?
> >  If no one knows them, then expect to have more of
> this in the future.
>

[David E Jones-2]

Discussion is just one part of decision making. Eventually a decision has to be made. My involvement in that issue was nothing more than it is in most cases: reviewing the decision and commenting on it.

-David


Chris Howe wrote:

> That's very interesting, David.  Considering that
> questioning of patterns is exactly what was being done
> in OFBIZ-81 and you of all people prompted others to
> dismiss the idea, even when the problem was
> articulated.
>
> --- "David E. Jones" <[hidden email]>
> wrote:
>
>> The best info to date on these things would be the
>> Framework Introduction videos and the Best Practices
>> Guide.
>>
>> Of course, anyone who has spent enough time with
>> OFBiz to have commit access in a certain area should
>> be familiar enough with the artifacts in that area
>> to recognize the established patterns.
>>
>> It's just like any effort to maintain consistency:
>> precedence is the key. Of course, precedence should
>> be questioned and reconsidered regularly and
>> sometimes even changed.
>>
>> If this is a problem, it is the duty of the
>> community (including me and all of us on this
>> mailing list) to fix it, especially those who
>> consider it a problem.
>>
>> -David
>>
>>
>> Adam Heath wrote:
>>> David E. Jones wrote:
>>>> In general please don't be too quick to change
>> things, especially that
>>>> are related to established patterns. Many of
>> these were established
>>>> after years of feedback and trying different
>> things and there are
>>>> always trade-offs with such things that one must
>> watch out for.
>>> Ok, so what are the established patterns?  Are
>> they documented anywhere?
>>>  If no one knows them, then expect to have more of
>> this in the future.
>>
>

[cjhowe]

Whether you want them to or not, David, most of the
people in the community assume that when you say to
ignore or not worry about someone's comment that
you're speaking from experience and are in the know on
the best practice.

That kind of kills discussion.

I'm of the opinion that this community should have the
mentality that if a decision has to be made, that it
be made in local, custom code.  The only decisions
that should be put into SVN are the _best_ decisions,
not just _a_ decision.

The only way to come to a _best_ decision is to point
out specifically, the strengths and weaknesses in the
options presented.


--- "David E. Jones" <[hidden email]>
wrote:

>
> Discussion is just one part of decision making.
> Eventually a decision has to be made. My involvement
> in that issue was nothing more than it is in most
> cases: reviewing the decision and commenting on it.
>
> -David
>
>
> Chris Howe wrote:
> > That's very interesting, David.  Considering that
> > questioning of patterns is exactly what was being
> done
> > in OFBIZ-81 and you of all people prompted others
> to
> > dismiss the idea, even when the problem was
> > articulated.
> >
> > --- "David E. Jones"
> <[hidden email]>
> > wrote:
> >
> >> The best info to date on these things would be
> the
> >> Framework Introduction videos and the Best
> Practices
> >> Guide.
> >>
> >> Of course, anyone who has spent enough time with
> >> OFBiz to have commit access in a certain area
> should
> >> be familiar enough with the artifacts in that
> area
> >> to recognize the established patterns.
> >>
> >> It's just like any effort to maintain
> consistency:
> >> precedence is the key. Of course, precedence
> should
> >> be questioned and reconsidered regularly and
> >> sometimes even changed.
> >>
> >> If this is a problem, it is the duty of the
> >> community (including me and all of us on this
> >> mailing list) to fix it, especially those who
> >> consider it a problem.
> >>
> >> -David
> >>
> >>
> >> Adam Heath wrote:
> >>> David E. Jones wrote:
> >>>> In general please don't be too quick to change
> >> things, especially that
> >>>> are related to established patterns. Many of
> >> these were established
> >>>> after years of feedback and trying different
> >> things and there are
> >>>> always trade-offs with such things that one
> must
> >> watch out for.
> >>> Ok, so what are the established patterns?  Are
> >> they documented anywhere?
> >>>  If no one knows them, then expect to have more
> of
> >> this in the future.
> >>
> >
>

[David E Jones-2]

Chris Howe wrote:
> Whether you want them to or not, David, most of the
> people in the community assume that when you say to
> ignore or not worry about someone's comment that
> you're speaking from experience and are in the know on
> the best practice.
>
> That kind of kills discussion.

Yes, that was kind of my intention. The discussion had gone on too long and didn't seem to have a good deal of benefit, especially not related to that issue.

> I'm of the opinion that this community should have the
> mentality that if a decision has to be made, that it
> be made in local, custom code.  The only decisions
> that should be put into SVN are the _best_ decisions,
> not just _a_ decision.
>
> The only way to come to a _best_ decision is to point
> out specifically, the strengths and weaknesses in the
> options presented.

Is that not what was done?

I'm sorry you disagree Chris. I can see by your increased activity in the project that want to become more involved, but there are better ways of doing so. I have no problem with the things you want to discuss being discussed, but in the proper context (like the dev mailing list). The difference might be difficult to see, but the best way to get involved is help move things forward, not question every decision that has been made and bring up reasons by things should not be done the way they are. In fact this is bordering on being categorized as complaining, or "trolling".

In the spirit of doing things the ASF way, which is quite well established, perhaps the following resources would be helpful:

http://www.apache.org/foundation/how-it-works.html#meritocracy

and:

http://www.apache.org/dev/project-mailing-lists.html#trolls

You can correctly infer by my including these links that I'm giving up trying to discuss it and appealing to an authority figure. Perhaps I shouldn't do either, maybe I'm justing wasting both of our time and only escalating the problem...

-David

[Andrew Sykes]

Si,

As an illustrative example, the following is a real pain...

06/07/06
On your side of the Atlantic that means 7th June 2006, but here in the
UK it is 6th July 2006.
--
Kind Regards
Andrew Sykes <[hidden email]>
Sykes Development Ltd
http://www.sykesdevelopment.com

[Leon Torres-2]

Andrew Sykes wrote:
 > Si,
 >
 > As an illustrative example, the following is a real pain...
 >
 > 06/07/06
 > On your side of the Atlantic that means 7th June 2006, but here in the
 > UK it is 6th July 2006.

In order to stave off future misunderstandings about this commit.  The
freemarker timestamp?string.medium_short method and friends is *already
localized*.  It will print the date format specific to your locale.

But even though it is localized, it is the wrong thing to do.  See David's
comments about the established patterns, which point out a more subtle issue.
And as I mentioned before, one potential solution is to overload
timestamp.toString().

It's perplexing how this blew up into such a big issue.  People are making a
mountain out of a molehill from this commit.

- Leon