Optimize Sankhya Dashboard Development
A skill for Sankhya ERP dashboard development - JSP/JSTL patterns, safe query parameterization, and BI visual consistency.
Why it matters
Streamline the creation and maintenance of Sankhya dashboards by providing best practices for JSP/HTML/Java code, UI/UX consistency, and efficient SQL queries.
Outcomes
What it gets done
Generate and review JSP/JSTL code for reduced errors.
Standardize BI component visual identity with CSS tokens.
Structure database queries for performance and correct entity mapping.
Guide HTML5 component flow for correct rendering and reactivity.
Install
Add it to your toolbox
Run in your project directory:
curl -fsSL https://spark.entire.vc/get/ag-sankhya-dashboard-html-jsp-custom-best-pratices | bash Overview
Sankhya Dashboard Html Jsp Custom Best Pratices
Sankhya Dashboard HTML/JSP Best Practices provides JSP/JSTL code patterns, parameter sanitization, CSS token-based visual identity, and structured SQL exploration for building dashboards and BI reports on the Sankhya ERP ecosystem. Use it when creating or modifying Sankhya BI dashboard code, queries, or visual identity; not for non-Sankhya ERP systems or generic JSP development.
What it does
Sankhya Dashboard HTML/JSP Best Practices is a consolidated guide of patterns for creating and maintaining dashboards, SQL queries, BI parameterization, and UI/UX within the Sankhya ERP ecosystem (JSP/HTML/Java). It covers four core capabilities: code generation and review applying JSP/JSTL patterns to reduce compilation errors and rendering failures; visual consistency via standardized CSS tokens across BI components; database exploration structured for performance and correct Sankhya entity mapping; and a BI construction guide for correct HTML5 component rendering, reactivity, and navigation.
Code best practices require declaring JSP directives and taglibs at the top of the file, forcing isELIgnored="false" to enable ${...} expression evaluation, preferring core_rt for JSTL core in the Sankhya ecosystem, avoiding Java scriptlets in favor of JSTL tags (c:if, c:choose, c:forEach), modularizing business logic into layers/services rather than single-file coupling, never hardcoding credentials or sensitive URLs, and persisting view preferences (column order, sorting) in localStorage with lazy-loading for heavy tabs/modals. A distinctive "parameter shielding" pattern always sets a fallback default for URL parameters via c:set to prevent a Java server 500 error, and a layer-separation pattern avoids injecting JSP tags directly inside <script> blocks by passing data through hidden HTML containers instead, keeping IDE linting healthy.
It shows safe consumption of snk:query results by iterating query.rows (not the root object) and testing emptiness with empty query.rows, plus a concrete SQL-injection-safe parameter sanitization pattern: normalize the input, strip quote characters (" and ") before injecting into a query, and always define a safe fallback (e.g. '0') to avoid invalid SQL. Screen-state guidance covers global data lists reused across KPIs/charts/tables/modals, per-tab loaded flags to avoid redundant queries, and reloading data plus reopening context after a transactional update.
Visual identity guidance defines a CSS custom-property palette (--color-bg, --color-surface, --color-text, --color-success, --color-warning, --color-danger, --color-accent), consistent semantic coloring (success/warning/error/neutral), allowing SQL-driven color overrides via BKCOLOR/FGCOLOR columns, sticky headers and fixed columns for wide high-volume tables, and CSS-class-based row status differentiation (approved, partial, historical, critical) for fast operational reading.
Database exploration guidance covers using DBExplorer for inspecting tables/fields/indexes/views/procedures, respecting the configured row-return limit (e.g. DBEXPMAXROW), avoiding SELECT * on tables with BLOB/CLOB fields, and names the essential ecosystem table maps: dictionary tables (TDDTAB, TDDCAM, TDDOPC, TDDINS, TDDLIG), commercial/financial tables (TGFCAB, TGFITE, TGFTOP, TGFPAR, TGFPRO, TGFEST, TGFVAR), and security/access tables (TSIUSU, TSIGRU, TSIACI, TSIIMP). Recommended SQL patterns include joining versioned TOP records by CODTIPOPER plus change date (DHTIPOPER/DHALTER), using the (... = :P_PARAM OR :P_PARAM IS NULL) pattern for optional filters, and always parameterizing rather than using literal user input.
When to use - and when NOT to
Use this skill when creating or modifying Sankhya BI dashboard code (JSP/HTML/Java), writing SQL queries against Sankhya entities, parameterizing BI reports, or standardizing dashboard visual identity.
Do not use it for non-Sankhya ERP systems or generic JSP/JSTL development unrelated to the Sankhya ecosystem - the specific taglibs (snk:), table names, and parameter-shielding conventions are Sankhya-specific. Note the source itself flags that table and field names shown are representative and may vary by instance implementation.
Inputs and outputs
Input: a Sankhya dashboard, gadget, or BI report requirement, plus the relevant data entities.
Output: JSP/HTML/SQL following Sankhya conventions, for example the parameter sanitization pattern:
<c:set var="raw_codusu" value="${empty param.P_CODUSU ? '0' : param.P_CODUSU}" />
<c:set var="codusu_limpo" value="${fn:replace(raw_codusu, '\"', '')}" />
<c:set var="codusu_limpo" value="${fn:replace(codusu_limpo, '"', '')}" />
<c:set var="codusu_seguro" value="${empty codusu_limpo ? '0' : codusu_limpo}" />
<snk:query var="qAcessos">
SELECT CODUSU, NOMEUSU
FROM TSIUSU
WHERE CODUSU = :codusu_seguro
</snk:query>
Along with this it produces CSS token-based visual identity, safe snk:query consumption patterns, and structured database exploration queries.
Who it's for
Developers building or maintaining BI dashboards in the Sankhya ERP ecosystem who need concrete, ecosystem-specific JSP/SQL patterns rather than generic Java web development advice.
FAQ
Common questions
Discussion
Questions & comments ยท 0
Sign In Sign in to leave a comment.