We have almost upgraded to GWT-2.12.1, but we have few queries:-
1. We have to write *@RemoteServiceRelativePath("/abc")* in our *XYZ_Srv*
class.
Is there any way we can do it without writing
*@RemoteServiceRelativePath("/abc").* otherwise How can we make it not to
be hardcoded but get the Class Name in it.
2. We have to put the Servlet in web.xml file like
*<servlet> <servlet-name>loginServlet</servlet-name>
<servlet-class>com.demo.login.Login_SrvImpl</servlet-class> </servlet>
<servlet-mapping> <servlet-name>loginServlet</servlet-name>
<url-pattern>/login</url-pattern> </servlet-mapping>*
How we can generate it dynamically as we have a large number of
servlets to map so we want it to add in multiple file such that maintaining
it will be easy. I mean Dynamic ServletRegistration here.
3. also currently we are having all the projects to be served under*
com.demo.packageName*. Here we get duplicity as we have few packages with
same name under different project or Custom libs.
is it possible to have it like *com.demo.project1.packageName*,
*com.demo.project2.packageName*
On Wednesday, February 12, 2025 at 1:27:55 AM UTC+5:30 Leon wrote:
> Oh, but I agree, the nature of the GWT Canvas implementation is no driver
> at all in which methodology to use to implement your application.
> Which design approach should be used depends on what the development team
> masters best.
>
> The advantage of an OO approach - which I was trying to make clear but
> obviously failed - is that you can have the model work out the required
> functionality before you need to draw it out on the canvas. It has many
> advantages, one of which - in this case - is that you need a lot less
> complex actions from the canvas itself. The reason is not for performance,
> but it's a complexity reduction basically.
> For that reason OO is very practical on the backend, but given the unique
> nature of GWT it makes it very practical on the frontend too.
> To me, that is one of it's USP's.
>
> And we can agree to disagree on the FP.
> Whilst I can imagine that for script languages FP seems like a more
> natural fit, but for information systems where java shines, OO is the best
> fit.
> The FP adoption in java is not late to the party, but is more like Oracle
> following the trend trying to make java hip and luring the script
> developers to jump ship.
> So yeah, for FP in Java I would say it is definitely following a trend.
> But like I said, we can agree to disagree.
>
> The funny thing about software development is that it is a field in which
> mastery of the tools is often seen as mastery of the craft.
> Now try to explain that to a carpenter or a potter.
>
>
>
> On Tue, Feb 11, 2025 at 6:38 PM Colin Alworth <[email protected]>
> wrote:
>
>> Sorry if I was unclear - FP vs OO vs whatever really shouldn't matter. I
>> only brought it up because you mentioned "OO style" driving some choices.
>> The nature of the Canvas APIs shouldn't need to drive how you use them,
>> until you are so starved for performance that you can't afford any
>> indirection at all.
>>
>> I don't think it is fair to call it the current trend - to anyone. Java
>> upped its FP game in Java 8, 10 years ago - and I don't think anyone will
>> argue that Java ever gets to the party early, without years of
>> deliberation. JavaScript is perfectly usable as a functional language
>> (debatably more so than than Java even today, since we still need SAM
>> interfaces and can't just pass functions directly) and has been for 30
>> years since it was first released.
>>
>> React's strategy effectively required that they adopt a "stateless"
>> paradigm, which lends itself very well to encouraging (ostensibly) pure
>> functions for rendering, that accept the state/props as an argument.
>>
>> On Sunday, February 9, 2025 at 2:39:00 AM UTC-6 [email protected]
>> wrote:
>>
>>> Switching to functional is the current trend I guess. Now you can argue
>>> whether or not it's smart to change design approach because it's a trend.
>>> As a framework - probably yes as you get higher adoption rates.
>>> As an application developer probably not - as it just creates extra
>>> maintenance for when the next trend comes around.
>>>
>>> On Sun, Feb 9, 2025 at 12:30 AM Craig Mitchell <[email protected]>
>>> wrote:
>>>
>>>> > *OO vs procedural/functional is quite the different design approach.
>>>> I would even say that those are worlds apart.*
>>>>
>>>> Tell that to the React creators, that switched the framework from OO to
>>>> functional. 😝
>>>>
>>>> On Sunday, 9 February 2025 at 8:49:40 am UTC+11 Leon wrote:
>>>>
>>>>> I can see where you say a developer familiar with the DOM is more
>>>>> likely to work with on the canvas api directly.
>>>>> And yes, the more technical options the better. Sure.
>>>>> But I do not see how you can say that an OO vs procedural or
>>>>> functional approach is not that relevant? OO vs procedural/functional is
>>>>> quite the different design approach. I would even say that those are
>>>>> worlds
>>>>> apart. In what way do you think that this difference not relevant?
>>>>>
>>>>>
>>>>> On Sat, Feb 8, 2025 at 8:53 PM Colin Alworth <[email protected]>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> @Craig - If you draw everything on the same canvas, the zoom/scale
>>>>>> works on everything on that canvas. it limits what you can do with that
>>>>>> canvas. If you want to scale or zoom everything, yes then it doesn't
>>>>>> matter. So yes you are right, it depends on the project.
>>>>>>
>>>>>> This isn't true, it only applied on the operations that take place
>>>>>> while it is set. You can call scale(1, 1) to go back to 1:1, or you can
>>>>>> use
>>>>>> the save()/restore() that Craig mentioned. You can also clip to keep the
>>>>>> zoomed content within certain bounds.
>>>>>>
>>>>>> @Colin - With multiple layers I would also need multiple canvas's and
>>>>>> overlay them right?
>>>>>>
>>>>>> Correct - each would have its own frame buffer, and could be
>>>>>> cleared/drawn independently.
>>>>>>
>>>>>>
>>>>>> We wrote a single adapter widget that uses a single canvas. This
>>>>>> adapter widget knows what the zoom level is. Objects that are drawn on
>>>>>> that
>>>>>> widget of a certain type get zoomed, whilst others of a different type
>>>>>> do
>>>>>> not. It is super simple and easily explained to new devs. Everyone on
>>>>>> the
>>>>>> team can add views or objects and the type determines how these are
>>>>>> displayed. Even devs without exact knowledge of how the canvas works can
>>>>>> develop and maintain objects to be displayed.
>>>>>>
>>>>>> I guess it's also a development style/preference thing. If you code
>>>>>> the view of the canvas in a single class or single method, the solution
>>>>>> is
>>>>>> likely to have to rely more on the technological capabilities of the
>>>>>> canvas. Working with an adapter then does not really make a lot of
>>>>>> sense.
>>>>>> If you have more of an OO style of development, you express more in
>>>>>> functional blocks. Then you have to rely less on the technical
>>>>>> capabilities
>>>>>> as you can translate what needs to be done on the basis of what your
>>>>>> objects are before you hit the canvas. Then the zooming/scaling happens
>>>>>> in the object, not on the canvas so to speak.
>>>>>> So the required functionality of the canvas remains fairly basic.
>>>>>>
>>>>>> I don't make these suggestions lightly - if you are happy with how
>>>>>> canvas performs and the quality of the output, then you may well never
>>>>>> need
>>>>>> them, but it can be fun to know they exist.
>>>>>>
>>>>>> I don't much care about OO vs FP styles for this - building an API
>>>>>> around these features should be straightforward within whatever paradigm
>>>>>> you prefer. For most projects we ended up with roughly two layers of
>>>>>> abstractions - the "shapes that get drawn on the screen via canvas
>>>>>> commands" abstraction (iterate through "shapes", respect their "z-index"
>>>>>> or
>>>>>> other relative positioning, capture clicks and figure out which "shape"
>>>>>> was
>>>>>> clicked on, redraw only changed "shapes" and those that intersect them,
>>>>>> etc), and the "business logic drives what shapes to draw" abstraction
>>>>>> ("I
>>>>>> want a pie chart in the corner, compute slices based on data", "these
>>>>>> buttons over here control those axes", "Labeled items in the legend will
>>>>>> drive which stars/circles in the chart are highlighted when hovered").
>>>>>> It
>>>>>> feels natural to someone who is used to working with a DOM (esp SVG),
>>>>>> and
>>>>>> can handle thousands of items without much trouble.
>>>>>>
>>>>>> Zoom can appear at either level here - multiple coord systems, or
>>>>>> make the "zoom" part of the "shape" API. You're totally correct that
>>>>>> scaling need not happen at the "canvas level" - while the MDN link I
>>>>>> gave
>>>>>> seems to imply that, it really is just trying to make it easier for the
>>>>>> developer to not need to think about one more "layer" of ways that their
>>>>>> data needs to be transformed. From a certain perspective, you might want
>>>>>> to
>>>>>> just have a transform matrix that you apply to each shape, and compose
>>>>>> your
>>>>>> zoom-because-zoom-widget, translate-because-panning, rotate, etc
>>>>>> operations
>>>>>> all at that level, and just apply the transform once when drawing (or
>>>>>> even
>>>>>> apply to the coords before you call in to canvas). None of it matters as
>>>>>> long as the math is correct.
>>>>>>
>>>>>> If you need more power, odds are you can find pretty quickly where
>>>>>> the "unnecessary" O(n^2) or O(n lg n) operations are taking place
>>>>>> (sorted
>>>>>> insertion by z-index, solving for intersections, etc), and can do a
>>>>>> better
>>>>>> job partitioning "shapes" or go all out and drop down to just "business
>>>>>> logic drives canvas commands" where it is required.
>>>>>>
>>>>>>
>>>>>>
>>>>>> performance wise, I've done fully animated person relation networks
>>>>>> and animated dashboards in large canvases for nearly a decade now.
>>>>>> We've never ran into any performance issues.
>>>>>> That being said, I think the views and on-screen actions we used were
>>>>>> somewhat limited when compared to developing a game with full world
>>>>>> rendering or something similar.
>>>>>>
>>>>>> Did I already say I love this gwt group? It makes me think a lot more
>>>>>> about what I am doing and why I am doing it.
>>>>>> Plus the input from the GWT devs usually give me insights I haven't
>>>>>> thought about before or didn't know existed.
>>>>>>
>>>>>> If you can stand the stream of discussion, you may also enjoy
>>>>>> https://matrix.to/#/#gwtproject_gwt:gitter.im. It tends to be more
>>>>>> conversational, and can get into the weeds in unrelated topics like this.
>>>>>>
>>>>>>
>>>>>> On Sat, Feb 8, 2025 at 2:56 AM Colin Alworth <[email protected]>
>>>>>> wrote:
>>>>>>
>>>>>> I'm sorry if my message confused the two kinds of 'zoom' being
>>>>>> discussed here - there's the one where the pixels on the physical
>>>>>> monitor
>>>>>> don't match the pixels of your display (this covers both HDPI and ctrl
>>>>>> +/-), and there's the one where the user clicks the + icon (drawn on the
>>>>>> canvas) to make everything inside a specific rectangle bigger.
>>>>>>
>>>>>> The context2d.scale() method can do both, but I was mostly referring
>>>>>> to the first, adapting to the user's current monitor+settings at any
>>>>>> given
>>>>>> time. Note that in this context, scale() does _not_ make things blurry
>>>>>> when
>>>>>> you zoom, but effectively multiplies all your coordinates by the scale.
>>>>>> The
>>>>>> canvas "height" and "width" (the "actual size" in the link's code
>>>>>> sample)
>>>>>> are what makes things blurry or super precise.
>>>>>>
>>>>>> In the second case, scale() can still be totally appropriate,
>>>>>> especially if coupled with a "panning" feature, or if data is updating.
>>>>>> Odds are very high that in those cases, the parts of the canvas outside
>>>>>> the
>>>>>> "rectangle" aren't moving - all the various controls, the rectangle
>>>>>> itself.
>>>>>> Avoiding redrawing whatever you can each frame is important for
>>>>>> performance. Or, you can just adjust your coordinate system when
>>>>>> projecting
>>>>>> on to the canvas, multiplying by your current zoom factor for each
>>>>>> position
>>>>>> - as above, it is doing the same thing.
>>>>>>
>>>>>> While we're discussing it, clipping (with save/restore or without)
>>>>>> still also be helpful to conserve rewrites too - if you had a single
>>>>>> canvas
>>>>>> element, you would clip to inside the rectangle, clear, and redraw only
>>>>>> what is in there - save() and restore() are a valid way of handling
>>>>>> that,
>>>>>> or just reapply state at each pass. If you're careful, you could even
>>>>>> just
>>>>>> redraw a subset of the rectangle's contents - solve for which items
>>>>>> actually changed (doing some intersection math), and clip+clearRect just
>>>>>> that section, then redraw just what is in there. If you "draw" a little
>>>>>> outside the clip in any of these cases, no big deal - it will get
>>>>>> clipped
>>>>>> out (but you'll still pay for the code to run, it just won't have any
>>>>>> overdraw).
>>>>>>
>>>>>> If you think about this like "partitioning" the drawing area with
>>>>>> clip, there are two other ways to partition too - you can "tile"
>>>>>> canvases,
>>>>>> selectively redrawing their entire contents if they are affected, and
>>>>>> you
>>>>>> can "layer" them, using transparency to enable lower layers or higher
>>>>>> layers to remain intact when other layers need to be cleared and
>>>>>> repainted.
>>>>>> Tiling can also work with non-homogenous blocks - the "rectangle" above
>>>>>> could be one canvas, and the "controls" could be in their own.
>>>>>>
>>>>>> On Friday, February 7, 2025 at 5:11:41 PM UTC-6
>>>>>> [email protected] wrote:
>>>>>>
>>>>>> > *I would not use the scale functionality as it applies to the
>>>>>> whole canvas. *
>>>>>>
>>>>>> Whatever works for your project is best, however, the scale only
>>>>>> applies when you set it. And you can always reset it. Eg:
>>>>>>
>>>>>> // Save the current state
>>>>>> context2d.save();
>>>>>>
>>>>>> // Apply zoom
>>>>>> context2d.scale(xxx, xxx);
>>>>>>
>>>>>> // Draw zoomed stuff
>>>>>> ...
>>>>>>
>>>>>> // Reset the zoom
>>>>>> context2d.restore();
>>>>>>
>>>>>> This also lets browsers use the GPU to render (although, I'm not
>>>>>> actually sure if the scaling is done on the CPU or the GPU).
>>>>>>
>>>>>> On Friday, 7 February 2025 at 5:02:17 pm UTC+11 Leon Pennings wrote:
>>>>>>
>>>>>> I would not use the scale functionality as it applies to the whole
>>>>>> canvas.
>>>>>> I'd prefer to apply an adapter pattern for determining actual
>>>>>> coordinates on the canvas.
>>>>>> Then you can still have a toolbar, location display or slider for the
>>>>>> zoom factor in it's normal proportions and just have the actual content
>>>>>> you
>>>>>> want to show in a different scale.
>>>>>>
>>>>>> Op donderdag 6 februari 2025 om 13:33:12 UTC+1 schreef Colin Alworth:
>>>>>>
>>>>>> No problem - I wanted to be sure I didn't make a mistake, since I
>>>>>> haven't myself used canvas "in anger" in many years, and only loosely
>>>>>> keep
>>>>>> track of resources and advice on it.
>>>>>>
>>>>>> SmartGWT's "Draw" examples make the API look very similar to the GXT
>>>>>> "draw" packages - it isn't really a raster API at all, but a vector API
>>>>>> that just happens to be built on top of a canvas implementation.
>>>>>>
>>>>>> My recollection is that for fewer than around 1k-10k drawn items, SVG
>>>>>> is faster and simpler to understand than canvas, and canvas's benefits
>>>>>> only
>>>>>> start kicking in when the DOM gets too heavy to manipulate quickly each
>>>>>> frame. Looking briefly at the example page you shared a few weeks ago,
>>>>>> if
>>>>>> you were interested in getting into the low level details of how to do
>>>>>> the
>>>>>> drawing, your case perhaps could stand being remade in plain SVG -
>>>>>> always
>>>>>> high resolution. The benefits may be mostly for your own understanding
>>>>>> rather than any real observed performance improvements from running the
>>>>>> page (that said: dropping SmartGWT would appear to drop almost 8mb of JS
>>>>>> out of your 9+mb page).
>>>>>>
>>>>>> On Wednesday, February 5, 2025 at 9:46:51 PM UTC-6
>>>>>> [email protected] wrote:
>>>>>>
>>>>>> > Neil, I'm not sure where I appeared to have said that.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I am sorry, I did not intend to put words in your mouth.
>>>>>>
>>>>>> That was my understanding from your previous email stating
>>>>>> that canvas is a raster format. I misinterpreted your statements.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I apologize for that.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thank you,
>>>>>>
>>>>>> Neil
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Neil Aggarwal, (972) 834-1565, http://www.propfinancing.com
>>>>>>
>>>>>> We offer 30 year loans on single family houses!
>>>>>>
>>>>>> --
>>>>>> You received this message because you are subscribed to a topic in
>>>>>> the Google Groups "GWT Users" group.
>>>>>> To unsubscribe from this topic, visit
>>>>>> https://groups.google.com/d/topic/google-web-toolkit/E3P4xZ8SFCg/unsubscribe
>>>>>> .
>>>>>> To unsubscribe from this group and all its topics, send an email to
>>>>>> [email protected].
>>>>>> To view this discussion visit
>>>>>> https://groups.google.com/d/msgid/google-web-toolkit/0e1b79f7-fa2e-482f-899b-65c5e9ca3e72n%40googlegroups.com
>>>>>>
>>>>>> <https://groups.google.com/d/msgid/google-web-toolkit/0e1b79f7-fa2e-482f-899b-65c5e9ca3e72n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>>> .
>>>>>>
>>>>>> --
>>>>>> You received this message because you are subscribed to a topic in
>>>>>> the Google Groups "GWT Users" group.
>>>>>> To unsubscribe from this topic, visit
>>>>>> https://groups.google.com/d/topic/google-web-toolkit/E3P4xZ8SFCg/unsubscribe
>>>>>> .
>>>>>> To unsubscribe from this group and all its topics, send an email to
>>>>>> [email protected].
>>>>>>
>>>>> To view this discussion visit
>>>>>> https://groups.google.com/d/msgid/google-web-toolkit/c66862dd-bcfc-4516-b2bf-c5dc17a73deen%40googlegroups.com
>>>>>>
>>>>>> <https://groups.google.com/d/msgid/google-web-toolkit/c66862dd-bcfc-4516-b2bf-c5dc17a73deen%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>>> .
>>>>>>
>>>>> --
>>>> You received this message because you are subscribed to a topic in the
>>>> Google Groups "GWT Users" group.
>>>> To unsubscribe from this topic, visit
>>>> https://groups.google.com/d/topic/google-web-toolkit/E3P4xZ8SFCg/unsubscribe
>>>> .
>>>> To unsubscribe from this group and all its topics, send an email to
>>>> [email protected].
>>>>
>>> To view this discussion visit
>>>> https://groups.google.com/d/msgid/google-web-toolkit/7299cb42-a00a-415a-b6a6-c8718ce1f9ddn%40googlegroups.com
>>>>
>>>> <https://groups.google.com/d/msgid/google-web-toolkit/7299cb42-a00a-415a-b6a6-c8718ce1f9ddn%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "GWT Users" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/google-web-toolkit/E3P4xZ8SFCg/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to
>> [email protected].
>>
> To view this discussion visit
>> https://groups.google.com/d/msgid/google-web-toolkit/778e24ce-c26e-4170-a346-755129440140n%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/google-web-toolkit/778e24ce-c26e-4170-a346-755129440140n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>
--
You received this message because you are subscribed to the Google Groups "GWT
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/google-web-toolkit/ddde2908-e28a-4768-8f6e-31e9d61a939dn%40googlegroups.com.
